-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Requiring field to be missing #128
Comments
Hey @slavafomin - Unfortunately not right now. I like the idea, though. I'm worried that |
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. So, if you would like to stick to the common "linting" syntax, then the correct way would be to name the rule as 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 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 |
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. |
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:
but it's not working. Is there a way to negate the rule perhaps?
Thanks!
The text was updated successfully, but these errors were encountered: