Support for "message" with "patterns" in `no-restricted-imports`
See original GitHub issueThe following issue is exactly what I’ve run into, but I can’t comment an interest in it because comments are restricted to me: https://github.com/eslint/eslint/issues/9846
Seems like one would want to see a message explaining why a certain pattern is restricted.
What rule do you want to change? no-restricted-imports
Does this change cause the rule to produce more or fewer warnings? Same
How will the change be implemented? (New option, new default behavior, etc.)? New option to create custom messages for pattern-based configurations
Please provide some example code that this change will affect:
Consider the following rule:
{
// No deep imports
'no-restricted-imports': [1, {patterns: ['*/*', '!@*/*', '!.*/*', '@*/*/*']}]
}
It would warn on:
import {thing} from 'some-package/utils'
// or
import {thing} from '@workspace/some-package/utils'
But pass these:
import {thing} from 'some-package'
// or
import {thing} from '@workspace/some-package'
A developer will only see the following from esw
:
import is restricted from being used by a pattern no-restricted-imports
However, I would like to notify them that this import is restricted because it violates an organization-wide “Deep import” rule.
What does the rule currently do for this code? Report an error on each line using the generic message for this rule.
What will the rule do after it’s changed? Report an error on each line using the generic message for this rule plus the message supplied in the configuration file.
Are you willing to submit a pull request to implement this change? If I was assured that it’d be merged in, perhaps… but there would be a fair amount of code familiarization.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:5
- Comments:7 (3 by maintainers)
Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.
Thanks for contributing to ESLint and we appreciate your understanding.
This is closed but it’s something that I would love to see.
I have a package with two styles of outputs,
lib/*
is commonJS exports (for a node server that consumes the package), andes6/*
is ES6 module exports (for tree-shaking on the frontend).But if you use the
lib/
imports in the web side, you don’t get tree-shaking; and if you use thees6/
imports in the node side, node will crash (but typescript won’t tell you you’re doing anything wrong).The
patterns
style rule works perfectly for this, but the error message is less than great - I’d love to tell people to just change the import to the proper subdirectory.