no-extraneous-dependencies: option to allow resolved dependencies
See original GitHub issueI have a case of where pkg1
depends on pkg2
and I like to import pkg2
to work with it directly without having to add a potentially conflicting/duplicate version of pkg2
to package.json
. Suggesting an option like allowResolved
to no-extraneous-dependencies to not trigger the rule when the imported package is resolvable.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
no-extraneous-dependencies : add an option to allow specific ...
i think I can see an argument for an option specifying that a specific package must be in devDependencies, even if all other...
Read more >Why (and How Can I FIx) ESLint import/no-extraneous ...
I solved it simply by setting devDependencies to true. ... for 'Definition for rule 'import/no-extraneous-dependencies' was not found'.
Read more >node_modules/eslint-plugin-import/CHANGELOG.md - PLMlab
no -extraneous-dependencies : packageDir option with array value was clobbering package deps instead of merging them (#1175/#1176, ...
Read more >eslint-plugin-import - npm
Ensure imports point to a file/module that can be resolved. ... Forbid the use of extraneous packages ( no-extraneous-dependencies ) ...
Read more >eslint/eslint - Gitter
4:1 error 'assert' should be listed in the project's dependencies. Run 'npm i -S assert' to add it import/no-extraneous-dependencies. Roy Sutton. @webOS101.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
It’s resolvable because I know beforehand that
pkg1
has a dependency on it, but I still need to interface directly withpkg2
to change one of it’s global settings, for example. I want to avoid putting it in package.json because that could lead to a situation with two versions being installed like this:mypackage > pkg2@2.0.0 mypackage > pkg1 > pkg2@1.0.0
which is bad because those can confict and it’s unnecessary extra bundle size. What I want is
mypackage > pkg1 > pkg2@1.0.0
while still being able to configure
pkg2
but this rule prevents that from happening.I don’t think it’s actually slim - yarn has overrides, and npm is planning to add them.
I’ll close this for the time being. Thanks for the discussion!