Open FerrielMelarpis opened 5 years ago
There's no way for the tool to just know that this is an alias on your system.
I see two possible solutions here:
// eslint-disable-line @wordpress/dependency-group
to your code to disable the line thereThere's no way for the tool to just know that this is an alias on your system.
I expect this is not specifically an alias on @FerrielMelarpis's system, and rather an alias configured via the webpack "alias" option, e.g.
resolve: {
alias: {
components: path.resolve( __dirname, '../app/block-editor/components' ),
},
},
I've noticed this particular issue as well, and do wonder if eslint could somehow parse the active webpack config and exclude any registered aliases from this rule.
The issue is obviously not hyper-critical, but it would be nice to resolve so the comments are as accurate as possible.
Sorry, yeah, that's what I meant. s/system/setup
.
I think an ESLint rule should not need to be aware of Webpack configuration and stay independent.
Hence my suggestion to allow adjusting the rule's option.
For example, the complexity
rule allows customization like this:
"complexity": ["error", { "max": 2 }]
For the @wordpress/dependency-group
rule it could work as follows:
"@wordpress/dependency-group": ["error", { "isInternalDependency": "^\." }]
Where ^\.
is the regex that is applied to the package name. ^\.
is the default to match current behavior:
IMHO that would be the proper way. If that makes sense I could try implementing it.
But anyways, I added the "Needs Technical Feedback" label to get more feedback on this 🙂
Thanks for the info @swissspidy I would love to have that kind of flexibility 👍 In the meantime, I just disabled that rule since it is not critical info in my code setup. I just find those comments helpful so I might use it again once it got support for custom regex rules.
The @wordpress/dependency-group
rule was removed from the recommended config somd time ago. See https://github.com/WordPress/gutenberg/blob/master/packages/eslint-plugin/CHANGELOG.md#300-2019-08-29
This should be no longer an issue.
@gziolo But the rule still exists and could be improved, no?
But the rule still exists and could be improved, no?
Right, we can reopen and change the title 👍
Would be great if this was extensible via the ESLint config as @swissspidy mentioned 🙏 . It might be a bit cleaner if this could be a single pattern OR a list of regex patterns to avoid a single highly-complex pattern for all. Then the plugin need only find if any of the provided patterns match.
patterns.find( ( pattern ) => ( new RegExp( pattern ) ).test( source ) );
Even though it is no longer part of the recommended ruleset, this causes a problem for projects that wish to use this rule and use aliases.
I've been working on this ESLint plugin recently. Might just as well fix this bug once and for all too 👍
Will give it a go.
I've been working on this ESLint plugin recently. Might just as well fix this bug once and for all too 👍
Will give it a go.
I love your plan, thanks Pascal :)
@aaemnnosttv Please have a look at #20629. It's super simple, but perhaps already enough.
This rule has still some flaws and doesn't handle wildly unordered imports very well, but at least this helps with treating certain dependencies as internal ones.
Describe the bug When running
wp-scripts lint-js
, I getand the code that causes this is
The problem is
someModule
is not an external dependency.To reproduce Steps to reproduce the behavior:
wp-scripts lint-js
Expected behavior The error should be
and when running
--fix
it should useInternal
.Desktop (please complete the following information):