Eslint-plugin-import: Add ignore setting to no-extraneous-dependencies

[lukechilds]

It would be great if the import/no-extraneous-dependencies rule could be ignored project wide but only for certain dependencies.

import/no-unresolved already has this functionality with it's ignore regex setting.

This could also be a potential solution for https://github.com/benmosher/eslint-plugin-import/issues/496

[klimashkin]

Right.
It is really needed in two cases:

1. In case of Flow.
   For instance in typing react component.

import type {AnyReactElement, ReactChildren} from 'react-flow-types';

react-flow-types are obviously in devDependencies, it never goes to production

1. In case of __DEV__ environment variable (or process.env.development or whatever) when we dynamcally require packages from devDependencies for development only

if (process.env.NODE_ENV !== 'production' && __WHY_UPDATE__ === true) {
  const {whyDidYouUpdate} = require('why-did-you-update'); 
  const RedBox = require('redbox-react');

  require('expose-loader?Perf!react-addons-perf');
}

Without having ignore option in no-extraneous-dependencies rule, I have to add // eslint-disable-line import/no-extraneous-dependencies on such lines. But in case of Flow it hardly possible, because requires too many such lines, in all react components files

[ljharb]

Linting should be done in dev, not production, so all dev dependencies would always be present.

[klimashkin]

@ljharb Not sure I got what you meant.
Of course linting happens in dev.

But one of the purpose of no-extraneous-dependencies rule is to restrict accidental usage of packages from devDependencies in your application that is built with webpack for browser.
In previous message I described why it should allow exceptions - when developer knows that he uses package from devDependencies in built application but only in development mode. Otherwise developer needs to put, for instance, why-did-you-update into dependencies, which is wrong.

• I'm talking about application development process, not library

[ljharb]

Ah, I think I understand.

Would it perhaps make more sense to have an option that skips checking dev deps inside NODE_ENV === production blocks, or similar? An ignore list is just as hard to maintain and get right as individual ignore comments are (which is what I'd suggest in the meantime)

[klimashkin]

But variable name can be absolutely random, not everybody uses NODE_ENV.
And it would not solve imports of flow types, they are not conditional.

I don't think ignore list for that rule is harder to maintain than for others. We have only about 5-6 packages to ignore among our 160+ items in package.json

[panrafal]

@ljharb hey, any chances revisiting this? we could make a PR for that.
In our use case, we have special imports transformed later by babel (translations to be precise).
We have them ignored in import/ignore and import/no-unresolved.

I think, that no-extraneous-dependencies should either use import/ignore setting, or have their own ignore (or use the global setting as a fallback).

[ljharb]

It definitely might make sense for no-extraneous-deps to use the import/ignore setting.

[panrafal]

@ljharb I've made a PR in #943

[benmosher]

I think, like no-unresolved, it may make sense for this rule to have its own ignore setting instead of using the global import/ignore, as that setting is more intended to avoid parsing non-JS "imports" in build pipelines with lots of transpiling and/or plugins to make that possible (i.e. CSS modules).

[EvertEt]

Is there any progress on this?
We currently have a seperate repo containing our typescript types as ES modules. This package is in the devDeps as the types get removed during compilation and thus not needed during running. We found it impossible to ignore this single package (using core-modules or ignore).

If there is no progress, is there already an idea what the ideal solution would be? Would it be a own ignore setting based on glob or just package names?

[kalbert312]

This would be nice to have for TypeScript packages that only export types. Types are a devDependency in a leaf project but will never make it to production.

[tjx666]

@kalbert312 can't agree more