Skip to content
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

Open
slavafomin opened this issue Aug 5, 2019 · 5 comments
Open

Requiring field to be missing #128

slavafomin opened this issue Aug 5, 2019 · 5 comments
Labels
enhancement 👑 New feature or request
Milestone

Comments

@slavafomin
Copy link
Contributor

slavafomin commented Aug 5, 2019

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!

@tclindner
Copy link
Owner

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?

@tclindner
Copy link
Owner

Hey @slavafomin do you have thoughts on the question above?

@slavafomin
Copy link
Contributor Author

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.

@tclindner
Copy link
Owner

Thank you so much for the detailed response! I’ll take some time to review other linters and post back to you this weekend 🙌

@tclindner tclindner added this to the v5.0.0 milestone Nov 17, 2019
@tclindner tclindner added the enhancement 👑 New feature or request label Nov 17, 2019
@MrHBS
Copy link

MrHBS commented Nov 29, 2023

This would be fantastic to have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement 👑 New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants