Eslint-plugin-import: How to ignore a specified package in the `no-extraneous-dependencies` rule

[realduolaf]

Hi guys.

I don't want to bother you, but I really don't know how to handle this situation.

How do I ignore a specified package in this rule(no-extraneous-dependencies) in a case like this？

https://material-ui.com/styles/basics/#material-ui-core-styles-vs-material-ui-styles

when I import "@material-ui/styles"， I will get an error from eslint. But if I add the package to the dependencies, the package will not work as expected.

Thanks for all the answers~

[realduolaf]

really want help

[ljharb]

Why would it not work correctly if you add it to deps?

[Toromyx]

I have the same problem with electron. The reason why electron needs to be in devDependencies is discussed in this github issue and this stackoverflow question.

I opened pr #1571 to add a whitelist option to no-extraneous-dependencies.

[ljharb]

@Toromyx that issue implies that you have two package.jsons; is that the case for you?

[Toromyx]

No, this is not the case. The issue does not describe my case, this issue does. It also brought me to https://www.npmjs.com/package/eslint-plugin-import#importcore-modules which is the solution for this issue's original question.

The pull request #1571 is therefore not needed.

[realduolaf]

@ljharb

Thank you for your reply.

Why would it not work correctly if you add it to deps?

The reason is that @material-ui/core re-exported @material-ui/styles with default themes in @material-io/core/styles. If I add the package to dependencies, there are two copies of @material-ui/styles. This will lead to themes not work as expected.

reference: https://material-ui.com/styles/basics/#material-ui-core-styles-vs-material-ui-styles

I won't discuss the advisability of material-ui behavior, but I suggest adding a whitelist of this rules.

[ljharb]

I'm very confused. If you're typing a package name into your code to import/require from, it should be in dependencies, or else it won't work (without incredibly nonstandard tooling that will massively confuse developers). Are you saying that using material-ui forces this scenario?

[magicmark]

babel macros might be an exception here?

they're package names you type into code and import from, but could get removed totally at buildtime/runtime

This has come up here: https://github.com/lingui/js-lingui/issues/409

[ljharb]

That seems like a very strange thing to want to do and a very good way to massively confuse anybody who looks at that code :-/

In that particular case, I'd think you'd absolutely want it to be listed in your dependencies so any peer dep or transitive dep requirements it has can be satisfied.

Is there a concrete use case (or macro) you're thinking of where the thing you type into your code won't actually be an installable module?

[magicmark]

¯_(ツ)_/¯ I agree it's certainly confusing at the very least :p

Also your point about macro deps not being transitively installed if the package in question is itself a library that will be installed elsewhere is an excellent one...not sure how that's supposed to be dealt with.

Regular deps certainly seems to make sense to me.

Worth pointing out the docs for both js-lingui and babel-plugin-macros itself suggest installing macros as devDeps:

• https://github.com/kentcdodds/babel-plugin-macros#should-macros-be-dependencies-or-devdependencies
• https://lingui.js.org/ref/macro.html#installation

Can't seem to find discussion around this though - might be worth looping in some of those folks to see if there's anything we're missing

[ljharb]

I think in the absence of a concrete use case, where it isn't both possible and advisable to install the "thing named by the specifier" as an explicit dep/dev dep, this isn't something that should be allowed.

Happy to reopen if a use case presents itself.

[Livven]

Not sure I understand why Babel macros aren't a valid use case here. Since packages generally ship transpiled code macro deps should not be necessary anymore.

This feature already exists anyway with the import/core-modules setting as noted in #1571.

[ljharb]

@Livven it's not that babel macros aren't a valid use case; it's that nobody's presented a use case where the specifier in the code shouldn't also be a regular dependency in package.json (so as to get all the features of semver, peer deps, etc).

The deps should be there whether they're used or not, for compatibility reasons with the consumer.