no-extraneous-dependencies: option to allow resolved dependencies

[silverwind]

I have a case of where pkg1depends 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.

[ljharb]

Can you help me understand why it would be resolveable, but why you wouldn't want it in package.json?

[silverwind]

It's resolvable because I know beforehand that pkg1 has a dependency on it, but I still need to interface directly with pkg2 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.

[xyuanbuilds]

It's resolvable because I know beforehand that pkg1 has a dependency on it, but I still need to interface directly with pkg2 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.

Is there any follow-up?

[ljharb]

@silverwind if one thing requires v1 and another v2, then in fact they are both necessary, and the bundle size increase is as well. If they can be deduped, they should be, and then there'd be no need to alter the linter to cover that.

Additionally, pnpm and yarn 2 will refuse to allow you to import pkg2 unless it's in package.json.

[silverwind]

There's certainly modules out there that tend to this pattern, sometimes they expose pkg2 as pkg1.pkg2 resolving the issue but it's not always a given. I guess what would need to happen is that package managers start to accept a resolution path like "pkg2": "npm:pkg1/pkg2" but the chances of that happening are very slim.

I'm fine if you want to close this, such modules are generally better avoided in any case.

[ljharb]

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!