-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Support for "message" with "patterns" in no-restricted-imports
#11843
Comments
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
Okay, we've had two team members review this and be in favor of the change but I think more folks can look at this. I'll champion. @eslint/eslint-team Can we review this please? |
@platinumazure Are you still championing this? |
+1 for this to express interest :-) |
Been smashing my head against a wall trying to find a way to do this. +1 interest |
Folks, no need to leave a comment to express interest. There’s definitely enough interest. What we need now is someone to figure out if it’s possible to create a rule schema to validate such options while maintaining backwards compatibility. |
As I'm no longer a team member, I have removed my assignment and will not/cannot champion this rule. Would anyone else on the team like to champion this and drive this to completion? |
An issue with this model might be that patterns can be related, as noted in this comment by @platinumazure. The actual implementation treats /* eslint no-restricted-imports:["error", {
patterns:["foo/*", "!foo/good"]
}]*/
import bad from "foo/bad"; // error
import good from "foo/good"; // ok Technically, Schema proposed in #9846 covers this. An alternative with the path/patterns object could be something like: {
"rules": {
"no-restricted-imports": ["error", {
"paths": [{
"name": "moment",
"message": "Don't import moment"
}],
"patterns": [{
"group": ["import1/private/*"],
"message": "Do not use any modules in import1/private"
}, {
"group": ["import2/*", "!import2/good"],
"message": "Do not use any modules in import2 except import2/good"
}]
}]
}
}
Each group is a test for itself. If it matches, the import is restricted. To avoid any confusion about the behavior of string elements in a configuration with groups (flat list of strings basically represents a group), I think that a mix of strings and objects in the |
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
I'll champion this. |
I am also interested in this happening - how can I help? |
I'm wondering if we can simplify the options of the rule, similar to node/no-restricted-import. |
If we are writing a new rule, then I think we should definitely choose one of the schemas proposed in this comment by @mysticatea. But, since we already have the rule with defined schema, I'd vote for this solution, as it looks like a minimal addition to the existing schema and the logic that handles configuration. |
That sounds reasonable. Is the next step to produce an RFC? (This issue is flagged as needing a design, so double checking.) |
If we all agree on this schema, then I think an RFC wouldn't be necessary, as it's a small backwards-compatible addition. If that schema doesn't look good, and/or we'd prefer to redesign the rule instead, then it would be probably better to go through the RFC process. |
Works for me. If no one else objects, let’s move forward with that. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
😢 |
Folks, let’s keep the discussion professional, please. Sarcasm isn’t helpful. In case it wasn’t clear, this issue has been accepted and is available for anyone to implement. This schema is the agreed-upon approach. We are looking for a community member to implement this as we are busy preparing ESLint for v8.0.0. |
I needed this for a big project, so made it as a custom rule locally as per to the defined schema and opened the above PR for feedback. #14580 Happy to put a bit of time into getting it mergeable if there's any change suggestions. |
…) (#14580) * Update: no-restricted-imports rule with custom messages (fixes #11843) * Update docs/rules/no-restricted-imports.md Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com> * Update docs/rules/no-restricted-imports.md Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com> * Code review feedback - better test cases and schema change * Doc updates * Added correct/incorrect examples to docs Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Creating a new request for a closed issue, as suggested here.
What rule do you want to change? no-restricted-imports
Does this change cause the rule to produce more or fewer warnings? Neither
How will the change be implemented? (New option, new default behavior, etc.)? Allow a new format for an existing option
Please provide some example code that this change will affect:
What I'd like to do in my ESLint config:
What does the rule currently do for this code? I can't customize the error message for the restricted pattern import
What will the rule do after it's changed? It should allow me to customize the error message for the restricted pattern import
Are you willing to submit a pull request to implement this change? Sure, though I'd like to get some clarity on how difficult the "large option schema change" mentioned here would be.
The text was updated successfully, but these errors were encountered: