npm-package-json-lint
npm-package-json-lint copied to clipboard
Requiring field to be missing
Hello!
Is there a way to require field to be missing? For example, I want bundledDependencies
field NOT TO be present in the manifest.
I've tried:
{
"require-bundledDependencies": ["error", false]
}
but it's not working. Is there a way to negate the rule perhaps?
Thanks!
Hey @slavafomin - Unfortunately not right now. I like the idea, though. I'm worried that require-bundledDependencies
false might get confused with an optional property. What do you think? Do you think it makes more sense to negate the require-*
rules or add no-bundledDependencies
or something else?
Hey @slavafomin do you have thoughts on the question above?
Looking at other linters, like ESLint, the are rules which could work in multiple directions, like in our example. Such rules have a broader name, e.g. block-spacing
, instead of no-block-spacing
or require-block-spacing
, and they could have multiple values like always
or never
.
So, if you would like to stick to the common "linting" syntax, then the correct way would be to name the rule as bundledDependencies
and allow it to be either always
, or never
.
However, I think that the more specific schema could be used to specify how the manifest should be structured. It could look something like this:
{
"fields": {
"name": {
"required": true,
"validators": [
"package-name"
]
},
"version": {
"required": true,
"validators": [
"semver"
]
},
"bundledDependencies": {
"forbidden": true
},
"author.name": {
"required": true,
"validators": [
"person-name"
]
},
"author.email": {
"required": true,
"validators": [
"email"
]
},
"author": {
"required": true,
"validators": [
"person-string"
]
},
"contributors": {
"isArray": true,
"itemValidators": [
"person-object"
]
},
"contributors": {
"validators": [
"persons-list-as-strings"
]
}
}
}
Such syntax would allow very powerful validations to be performed. This library could provide a number of validation functions to be tailored to the package.json manifests, like persons-list-as-strings
, package-name
, etc.
And due to it's flexibility, such syntax could be used to validate different data structures no matter the source format (JSON, YAML, etc). Probably, there should be existing libraries which do exactly that, maybe we could use one of those and build on top of it.
Such approach would also allow to remove a big list of very similar rules and to replace them with more reusable validation functions. Developer will be able to validate custom fields in their manifests and will be able to even implement their own validators, which could be loaded as plugins, e.g. to validate webpack-specific fields like sideEffects
, browser
, module
and so on.
Thank you so much for the detailed response! I’ll take some time to review other linters and post back to you this weekend 🙌
This would be fantastic to have.