Make no-restricted-imports apply to dynamic imports

What rule do you want to change? no-restricted-imports

Does this change cause the rule to produce more or fewer warnings? More

How will the change be implemented? (New option, new default behavior, etc.)? New default behaviour would make sense, although could be an opt-in via option too.

Please provide some example code that this change will affect:

await import('restricted');

What does the rule currently do for this code? Nothing.

What will the rule do after it’s changed? Report an error just as if it was a sync import.

Are you willing to submit a pull request to implement this change? Maybe

[mdjermanovic]

If this enhancement doesn’t reach consensus, an alternative is to configure no-restricted-syntax rule.

For example, this disallows importing foo and anything from bar/:

/* eslint "no-restricted-syntax": [ "error",
  {
    "selector": "ImportExpression > Literal.source[value='foo']",
    "message": "Don't import 'foo'."
  },
  {
    "selector": "ImportExpression > Literal.source[value=/^bar\\x2F/]",
    "message": "Don't import 'bar/*'."
  }
]*/

import("foo"); // Don't import 'foo'. (no-restricted-syntax)

import("bar/baz"); // Don't import 'bar/*'. (no-restricted-syntax)

Online demo link

[mdjermanovic]

May be behind an option with something like dynamicImport: Boolean makes sense as the dynamic import is available from 2020 ECMA version.

Or perhaps enable it by default if version >= 2020.

New default behavior would be a breaking change, because the rule currently doesn’t check dynamic imports and ESLint already supports dynamic imports for over a year now.

Since this change results in ESLint reporting more linting errors, and it isn’t a bug fix, per our semver-policy we would have to either wait for the next major version, or add an option with a default value that retains the current behavior of this rule.

ecmaVersion >= 2020 is basically the same as not checking ecmaVersion at all, because this syntax isn’t available in ecmaVersion < 2020.

I’m not sure how useful this feature would be

I’ll share our use case… We’re doing webpack code splitting using dynamic imports, and we use no-restricted-imports with patterns to enforce that things aren’t imported from places they shouldn’t be - which would result in them being in the wrong (or multiple) bundles.

Sorry, I wasn’t clear enough! There are certainly valid use cases, like with static imports.

The problem is that, unlike with static imports, we often can’t know the import source. Dynamic imports have dynamic specifiers; import() syntax allows expressions inside ():

We could say that the new option applies only to dynamic imports with static specifiers (i.e. string literals, like import("foo")).

Still, it might be confusing when combined with other configuration options. For example, user might expect an error on the dynamic import in the following case (assuming that the new option is enabled):

/*eslint no-restricted-imports: ["error", { "patterns": ["foo/*"] }]*/

import a from "foo/a"; // error

import(`foo/${bar}`); // error?

Also, the rule won’t be able to restrict just certain names from a module:

/*eslint no-restricted-imports: ["error", { "name": "foo", importNames: ["a"] }]*/

import { a } from "foo"; // error

import { b } from "foo"; // ok

import * as foo_ns from "foo"; // error, because `foo_ns` provides access to `a`

import("foo"); // always error?