`no-restricted-imports`: setting to to allow renames

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

Does this change cause the rule to produce more or fewer warnings? Fewer, if a setting is enabled

How will the change be implemented? (New option, new default behavior, etc.)? New option

Please provide some example code that this change will affect:

{
  rules: {
    'no-restricted-imports': [
      'error',
      {
        paths: [{ name: 'lib', importNames: ['Option'] }],
      },
    ],
  },
}

import { Option as LibOption } from 'lib';

What does the rule currently do for this code?

Errors

What will the rule do after it’s changed?

Not error, if a setting is enabled, e.g. allowRenames: true.

I want to disallow this code:

import { Option } from 'lib';

But allow this code:

import { Option as LibOption } from 'lib';

That is, I want to ban importing the named import Option from lib, but I want to allow that named import to be used if it is renamed to something else.

Example of using this setting:

{
  rules: {
    'no-restricted-imports': [
      'error',
      {
        paths: [{ name: 'lib', importNames: ['Option'], allowRenames: true }],
      },
    ],
  },
}

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

[platinumazure]

Personally, I lean towards this being an edge case, and would suggest creating a custom rule using eslint-rule-composer which could filter out linting reports for your specific case.

That’s just my opinion; other team members might feel differently.

[kaicataldo]

I agree with @platinumazure. This feels like a muddying of responsibilities of this rule. If you know what identifiers you want to allow, this should also be able to be enforced with no-restricted-syntax.