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
Rule proposal: no-wildcard-import #4865
Comments
@silvenon Thanks for the issue! If you're reporting a bug, please be sure to include:
Requesting a new rule? Please see Proposing a New Rule for instructions. |
|
In other words, why should this be part of the ESLint core and managed by us when you can write and manage it yourself? |
After giving it some more thought, I don't think it's a good rule to enforce. Forcing a single default export instead of named exports provides no benefit. |
That syntax doesn't import the default export, it imports all exports. |
Yes. I meant that not allowing wildcard imports will force you to write modules with a single (default) export. |
No it won't. |
// foo.js
export const a = 5;
export const b = 6; // bar.js
import * as foo from 'foo'; // oops, error, fixing...
import foo from 'foo'; // but that won't work, gotta rewrite foo.js... // foo.js
export default {
a: 5,
b: 6
}; // bar.js
import foo from 'foo'; // this works now
console.log(foo.a); |
Oh, I see what you meant, when you're importing only certain exports, it doesn't really matter whether it's a single exported object or a named export. |
Yes. import {a, b} from "foo"; |
What about the case when you are importing actions into a component? e.g. import * as awesomeActions from './actions/awesomeActions'; |
I disagree. Stylistic benefits aside, disallowing wildcard imports has several technical implications. For example, wildcard imports breaks treeshaking in Webpack (I know not everyone uses Webpack, and that this may not be reason enough to have it as a core rule, but still). |
Can this be reopened? I'd very much like to ban wildcard imports in all of my projects. |
Can this be enforced with |
Yes — just restrict |
I hadn't thought about that, good idea! {
"no-restricted-syntax": [
"error",
{
"selector": ":matches(ImportNamespaceSpecifier, ExportAllDeclaration, ExportNamespaceSpecifier)",
"message": "Import/export only modules you need"
}
]
} I haven't tested this, but it should prohibit all wildcard import and export statements: import * as foo from 'foo';
export * from 'foo';
export * as foo from 'foo'; Let me know if that works for you, @ljharb. |
It can, but that’s a blunt instrument that works very poorly with shared configs - since anyone wishing to modify any of the config for that rule needs to copy-paste the entire config and then tweak, to do it properly. I think |
Also, people will still often want to do How would configuration for this new rule look like? What would whitelisting look like? @platinumazure what do you think? |
I agree. I think it would be a good idea to improve this situation (e.g. with #9192) so that
I disagree, this rule seems completely redundant with |
I don’t think it makes them unnecessary; however, it should be able to make their implementation simply defer to that of no-restricted-syntax. There’s not actually much value in minimizing the number of distinct rules; whereas there is much value in abstracting away complex configuration (especially anything that deals with AST nodes) from eslint users. |
Completely disagree. ESLint has a huge number of rules. It's incredibly hard to find a rule that enforces specific pattern. Even as one of the maintainer, I have to constantly dig through documentation whenever creating my own config from the scratch. There is a very substantial value in minimizing the number of distinct rules from my perspective. |
I wouldn't completely disagree. Imagine you would have only 10 eslint rules which are capable of replacing any other rule - I can't imagine that everyone is able to understand the logic/language you would need to implement for this. I see no reason why making things complicated and screw up this nice module. If a programmer installs eslint and looks for this feature we won't say "Hey great. I have to learn so much stuff before I can start !". Vice versa imagine he would google for this rule and find it directly. In my opinion a lint library shouldn't be minimalistic. I agree that it should provide advanced rules for advanced users with very special rules. But it should also abstract away complexity by providing simple rules. Btw: if you're always starting your config from scratch you're definitely doing something wrong... |
For those who are wondering how to add this rule and add an exception for Reacts wildcard import: no-restricted-syntax:
- 2
- selector: :matches(ImportNamespaceSpecifier[local.name!='React']) # just add another square bracket for a second name matching
message: Import/export only modules you need {
"no-restricted-syntax": [
"error",
{
"selector": ":matches(ImportNamespaceSpecifier[local.name!='React'])",
"message": "Import/export only modules you need"
}
]
} Took me some time to make this work since the documentation on selectors is missing a lot of configurations (like the parameters of ImportNamespaceSpecifier). If you want to add similar rules or would like to see what options are available beside the documentation: Greetings, |
(Not sure why you’d need an exception for React; |
@Chaoste See https://github.com/estree/estree for the tree documentation. |
Thanks for the feedback! If it's not necessary I would also remove the exception. And thanks for pointing out the background of AST selectors - didn't know what this is all about ;) |
@Chaoste Also see https://github.com/estools/esquery for the selector syntax. |
Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn't get consensus from the team, so I'm closing it. We define consensus as having three Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn't need to be a blocker for you using this in your project, if you'd find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint. |
Found this rule in Airbnb's JS styleguide and I liked it.
The text was updated successfully, but these errors were encountered: