no-restricted-imports should support importNames on patterns exclusions

[xdumaine]

What rule do you want to change?

no-restricted-imports

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

Neither, it makes configuration more powerful

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

New options to the rule schema

Please provide some example code that this change will affect:

import { Foo, Bar } from '../../my/relative-module'
import { Foo } from '../../../my/relative-module'

What does the rule currently do for this code?

It's not currently possible to ban importing only a named import from a pattern ban. Nor is it possible to include a message for those bans.

What will the rule do after it's changed?

Could be configured as follows:

'no-restricted-imports: [
  'error',
  {
    patterns: [ '**/my/relative-module'],
    importNames: ['Foo'], // currently not supported for patterns
    message: 'Don't import Foo from my/relative-module. Instead import from @repo/foo', // currently not supported for patterns
  }
]

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

Potentially, but I'd like some guidance and my time is limited due to having young kids.

[mdjermanovic]

Hi @xdumaine, thanks for the issue!

It's not currently possible to ban importing only a named import from a pattern ban.

Is there a use case for restricting only a certain named import from a group of files that match the pattern?

Nor is it possible to include a message for those bans.

This is already accepted in #11843

[xdumaine]

The use case we have is that graphql codegen generates types for our resolvers and also exports some type helpers like Maybe, etc. Devs often use those but inadvertently cause circular dependencies.

I'd like to say "don't use the Maybe export from the generated code files" without banning other exports from those same files.

[mdjermanovic]

Thanks for the explanation, makes sense to me. I support this proposal 👍, let's hear what other team members think about it.

Given the accepted change #11843 (comment), configuration would be:

"no-restricted-imports": ["error", {            
    "patterns": [{
        "group": ["**/my/relative-module"],
        "importNames": ["Foo"],
        "message": "Don't import Foo from my/relative-module. Instead import from @repo/foo"
    }]
}]

[github-actions]

Oops! It looks like we lost track of this issue. @eslint/eslint-tsc what do we want to do here? This issue will auto-close in 7 days without an update.

[ljharb]

It'd be great if someone had time to make a PR (assuming it's accepted?)

[snitin315]

"no-restricted-imports": ["error", {            
    "patterns": [{
        "group": ["**/my/relative-module"],
        "importNames": ["Foo"],
        "message": "Don't import Foo from my/relative-module. Instead import from @repo/foo"
    }]
}]

So, the above config will result in the following behaviour:

import { Foo } from '../../../my/relative-module' // error
import { Foo, Bar } from '../../../my/relative-module' // error
import { Bar } from '../../../my/relative-module' // ok

It makes sense to me as well. I am also 👍🏻 on this. I can submit a PR for this if accepted.

[lekterable]

Coming here from #15236

Can this already be worked on or does it need some more approvals?
Also, @snitin315 are you still up to take this? if you're busy I might try 🙂

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[Akridian]

So @snitin315, @lekterable, can someone try to made a PR. Suddenly have no experience in this field to make one.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[ljharb]

bump

[jtwee]

I just came across this limitation when trying to disallow only a specific subset of exports from a given module. It works nicely for absolute paths, but to support relative paths I would need patterns. Is this likely to receive approval? And if so, would a PR attempt be welcome?

[xdumaine]

@jtwee yep, from previous comments, looks like a PR would definitely be very helpful.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[ljharb]

bump

[brandongregoryscott]

I took a stab at this over the weekend - will throw up a PR for feedback later today!

[nzakas]

@mdjermanovic if you think it’s a good idea then I’m 👍

[mdjermanovic]

This feature seems to have enough support from the team, so I'm marking this as accepted, and we already have a PR: #16059