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

feature suggestion: support exceptions for the "prefer-...-dependencies" rules #93

Closed
lddubeau opened this issue Sep 11, 2018 · 5 comments
Closed
Assignees
Projects
Milestone

Comments

@lddubeau
Copy link
Contributor

@lddubeau lddubeau commented Sep 11, 2018

I use rules like prefer-caret-version-dependencies. However, sometimes a dependency has a problem that requires me to specify a version range that cannot be represented with a caret version.

Looking at the documentation, I cannot see a way currently to specify exceptions to the rule. Either all dependencies are checked and if any of them don't use the caret syntax, I get an error. Or I have to turn off the rule or make it a warning. But a warning is not really the level of forcefulness I want. It is too easy to miss a warning.

@tclindner

This comment has been minimized.

Copy link
Owner

@tclindner tclindner commented Sep 14, 2018

Great suggestion, @lddubeau!

@ntwb

This comment has been minimized.

Copy link

@ntwb ntwb commented Mar 13, 2019

I just went searching the repo here for "exception", I've a use case in the monorepo we use @WordPress where 20 of the packages require require-module, and the other 20 do not.

So thinking on a wider note, there would be a use case for many of the rules in this package to allow exceptions of some sort.

@tclindner

This comment has been minimized.

Copy link
Owner

@tclindner tclindner commented Mar 16, 2019

@ntwb - I'm curious if you would prefer this for your monorepo scenario.
Use globs to specify different config for sub-packages (note the draft structure below is a breaking change. I'm not sure about this syntax 🤓. I'm curious where some for the RFCs for ESLint will go in 2019).

The linter would use the first config object for the root package.json file. The linter would use the second config object package.json files in the submodules directory.

[
  {
    "files": ["package.json"],
    "rules": {
      "require-module": "error"
    }
  },
  {
    "files": ["submodules/**/package.json"],
    "rules": {
      "require-module": "off"
    }
  }
]

@lddubeau - is your scenario more like this? Exceptions to rules where, for example, prefer-caret-version-dependencies is set but it doesn't check packages listed in an array of exceptions.

{
  "rules": {
    "prefer-caret-version-dependencies": ["error", {
      "exceptions": ["moduleToIgnore"]
    }]
  }
}
@lddubeau

This comment has been minimized.

Copy link
Contributor Author

@lddubeau lddubeau commented Mar 16, 2019

@tclindner Yep, within the same package.json the rule should generally apply but some modules should be ignored by the rule. Adding an exceptions field to configure the rule would do it.

@ntwb

This comment has been minimized.

Copy link

@ntwb ntwb commented Mar 20, 2019

Thanks @tclindner looking at the file glob example:

"files": ["submodules/**/package.json"],

I think having a glob pattern for ~20 paths, i.e. I want to exclude ~20 from the ~40 we have might get a little unwieldy.

Whereas, your second example with an array of modules to exclude I think looks a little cleaner:

{
  "rules": {
    "prefer-caret-version-dependencies": ["error", {
      "exceptions": [
		"moduleToIgnore1",
		"moduleToIgnore2",
		"moduleToIgnore3",
		]
    }]
  }
}
@tclindner tclindner added this to To do in v4 via automation Jun 16, 2019
@tclindner tclindner added this to the v4.0.0 milestone Jun 16, 2019
@tclindner tclindner self-assigned this Jun 22, 2019
@tclindner tclindner moved this from To do to In progress in v4 Jun 22, 2019
tclindner added a commit that referenced this issue Jun 29, 2019
Closes #93
@tclindner tclindner mentioned this issue Jun 29, 2019
1 of 1 task complete
@tclindner tclindner closed this in 973c603 Jun 29, 2019
v4 automation moved this from In progress to Done Jun 29, 2019
tclindner added a commit that referenced this issue Jun 29, 2019
* Remove validator and add ajv-errors

* Add new property exist module

* Add the ability to add exceptions

Closes #93

* Update format.test.js

* Update format.js

* Update format.js

* Enhance name format rule

Closes #115
tclindner added a commit that referenced this issue Jun 29, 2019
* Remove validator and add ajv-errors

* Add new property exist module

* Add the ability to add exceptions

Closes #93

* Update format.test.js

* Update format.js

* Update format.js

* Enhance name format rule

Closes #115

* Update alpha rules
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
v4
  
Done
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.