no-restricted-imports: allow some specific imports in some specific directories

[avasuro]

Hello,

I have a question and idea about no-restricted-imports rule.

Preconditions:

In my projects I often use the following approach: for every UI element that is provided by external library (e.g. @mui/material/Button) I create own wrapper, that re-exports library classes/types etc. that I use in my project. Somethnig like this:

// src/components/Button/index.ts
export {default, ButtonProps} from '@mui/material/Button';

And reuse this wrapper in all places in the project insead of direct imports from external libraries:

// In all places of the project instead of this:
// import Button from '@mui/material/Button';
// I do this:
import Button from 'src/components/Button';

This way, if later I would like to customize this component, or fix a bug or something else - I could do it by creating own Button.tsx with necessary customizations and reexport this customized version, so no changes in the outside code required. For example, to add default variant for the button I could do like this:

// src/components/Button/Button.tsx
import MUIButton from '@mui/material/Button';

export default function Button(props) {
  return <MUIButton {...props} variant={props.variant || 'contained'} />
}

and reexport this customized version instead of native one:

// src/components/Button/index.ts
export {default} from './Button.tsx';
export {ButtonProps} from '@mui/material/Button';

And to enforce all developers to use this button wrapper everywhere instead of direct imports from external library I use no-restricted-imports rule like this:

// ...
'no-restricted-imports': ['error', {
  paths: [
    { name: '@mui/material/Button', message: 'Import from @mui/material/Button is deprecated. Use "src/components/Button" instead.' }
  ]
}];

The problem

With the configuration above eslint gives error if I import '@mui/material/Button' inside my own button wrapper folder (src/components/Button), which is right behavior from the point of view of eslint, but it is not convenient for me, as in all places inside button wrapper folder I have to put eslint-disable comments.

I could disabe no-restricted-imports rule inside src/components/Button folder using "overrides" section of eslint like this:

overrides: {
  "files": ["src/components/Button/*"],
  "rules": {"no-restricted-imports": "off"}
}

but that will disable all no-restricted-import paths (and I have several there, like separate path for every UI component of the MUI library), which is not what I need - I need to allow import of "@mui/material/Button" but keep all the rest imports specified in no-restricted-imports rule prevented.

Question/Proposal

So my question is - do you know any other way how I could easily achieve desired behavior using curren eslint API?
And my proposal is - probably, it makes sense to add additional property to no-restricted-imports rule config (e.g. "exceptIn") that will "disable" this particular path in given folder (glob). like this:

'no-restricted-imports': ['error', {
  paths: [
    {
      name: '@mui/material/Button',
      message: 'Import from @mui/material/Button is deprecated. Use "src/components/Button" instead.' },
      exceptIn: ['src/components/Button/*'] // this will still allow import from @mui/material/Button inside src/components/Button fodler
  ]
}];

[mdjermanovic]

I could disabe no-restricted-imports rule inside src/components/Button folder using "overrides" section of eslint like this:

overrides: {
  "files": ["src/components/Button/*"],
  "rules": {"no-restricted-imports": "off"}
}

but that will disable all no-restricted-import paths (and I have several there, like separate path for every UI component of the MUI library), which is not what I need - I need to allow import of "@mui/material/Button" but keep all the rest imports specified in no-restricted-imports rule prevented.

Instead of disabling the rule, you could use overrides to set a configuration that doesn't disallow "@mui/material/Button".

[avasuro]

Yes, that will work. But a lot of custom code should be written to acieve that. If I have 20+ restricted imports of various UI components, then I also have to specify 20+ overrides rules, each will contain one and the same paths property of no-restricted-imports, but without one element that is related to this import path:

"no-restricted-imports": ['error', {paths: [
  // ... 20+ config objects here
]}],
"overrides": [
  // ...20+ config objects, that describe override for each view wrapper separately:
  // {
  //   files: somefile,
  //   rules: {"no-restricted-imports": ["error", [
  //     ...20+ array items (minus one that relates to the current override)
  // ]]}}
]

I could simplify if I create some sort of mapping from restricted import path to allowed one and reuse this config to generate proper config for eslint:

const restrictedImportsConfig = [
  {insteadOf: '@mui/material/Button', use: 'src/components/Button'}
  // ...20+ config object here
];

function restrictedImportsConfigToPath(config) {
  {paths:restrictedImportsConfig.map(({insteadOf, use}) => ({
    name: insteadOf,
    message: `Instaed of ${insteadOf} use ${use}`
  }))}
}

"no-restircted-imports": ["error", {
  paths: restrictedImportsConfigToPath(restrictedImportsConfig)
}],
"overrides": [
  ...restrictedImportsConfig.map(({insteadOf, use}) => ({
    files: [`${use}/*`],
    rules: {
        "no-restricted-imports": [
          "error",
          {
            paths: restrictedImportsConfigToPath(
              restrictedImportsConfig.filter(i => i.use !== use)
            )
          }
        ]
    }
  }))
  // ... other "overrides" rules if needed
]

But such approach looks overcomplicated.

Also, I understand that it is normal situation when we have to write complicated eslint config files to achieve some project-specific goals.
But, probably, this rule and this particual example deserves to be handled by esilnt out of the box. Because if you prevent import of something for whatever reason, there are big changes that you would like to still allow it in some very restricted area of application. And handling all of that manually every time looks overcomplicated, especially taking into account that there is no way to override/disable specific elements in paths array of no-restricted-imports rule via .eslintrc file in some specific folder.

[mdjermanovic]

We're using a similar pattern for configuring the n/no-restricted-require rule in the .eslintrc.js file of this project. For many rules it might make sense to have different configurations in different parts of the project. That's why ESLint provides overrides, so that this logic doesn't have to be implemented in every rule.

[avasuro]

Thank you for the link to the eslint config.
Agree with your argument about that overrides logic dosn't have to be implemented in every rule.