eslint-plugin-import
eslint-plugin-import copied to clipboard
Suggesting an `exceptTarget` param for `import/no-restricted-paths`
Hi there 👋
I'm having a bit of trouble with the import/no-restricted-paths
rule for a fine tuned setup. Given the following file structure, I'd like to lint our usage of subpath imports (with an ESLint warning) for the src/foo
folder and subfolders when importing them from outside those places (from src/bar
for instance), but not when importing from inside (from src/foo/fooSubDirA
for instance).
src
├── foo # Subpath import setup with `#foo`
├── fooSubDirA
└── fooSubDirB
└── bar
└── barSubDir
This should trigger an ESLint warning:
// src/bar/barSubDir/file.ts
import { something } from '../../foo/fooSubDirA/file'; // ❌ Unexpected path "../../foo/fooSubDirA/file" imported in restricted zone. Please use path mapping with the '#foo' alias instead.
This should work without any warning:
// src/foo/fooSubDirB/file.ts
import { something } from '../fooSubDirA/file'; // ✅
My understanding of the except
parameter is that it's a from
exception, not a target
one. I'd like to have a similar parameter, like targetException
or exceptTarget
to remove some target files from having to use a given subpath import. For my use-case, target
would be ./src
, and exceptTarget
would be ./src/foo
.
Do you think it's already possible with the currently available settings? If so, could you show me how I would do it? I'm aware I can use globs for targets, but I couldn't figure out how to say "everything, at any depth in my whole project, except this specific folder's content at any depth" with a glob. If that's currently not possible, would you be open to such an addition to the rule? I find it way easier to setup exceptions with "positive" matches rather than trying to setup negative ones (especially with globs, which are quite limited with exception patterns).
I'm well aware of the position of some maintainers here regarding subpath imports/path mapping in general, but I believe such a parameter could benefit more use-cases than just mine. The exceptTarget
param I'm suggesting would cover much more things that this, it's in no way associated to subpath imports or any other path mapping feature.
Since this plugin doesn't yet support "exports", let alone "imports", I don't think it makes sense to add features in their service yet.
Have you tried using overrides? In other words, rather than one rule config entry for the entire project, make one as a default, and then use overrides to add another just for the files you want to target (which i believe supports glob negations)
Sorry if I wasn't clear, I'm not suggesting that this plugin should natively support exports
or imports
fields in package.json
files, I'd just want an exceptTarget
parameter to see the light of day in the import/no-restricted-paths
rule. Frontend aliases for instance (with Webpack/other bundlers/resolved at build time) would also benefit the exact same setup, yet they leverage other mechanisms than subpath imports to work. My use-case of subpath imports was just to give an example, but I'd wager other people would eventually need that exceptTarget
parameter for totally different use-cases.
The problem with handling those exceptions with ESLint overrides is that I believe ESLint only allows the same negative glob patterns as this lib does, because they both use minimatch
, so I believe if I could make one work, the other would work just the same. And I just couldn't figure out how to solve this "apply to all, except here" thing with negative glob patterns.
@acidoxee you'd say "everywhere, do X" and "in this one place, do Y instead" as two overrides. You don't need negative glob patterns (altho that would also work)