[dependabot]

Bumps eslint-plugin-import-x from 4.17.1 to 4.18.0.

Release notes

Sourced from eslint-plugin-import-x's releases.

v4.18.0

Minor Changes

• #520 802441c Thanks @​SwastikTripathi! - Add a checkSelfReference option to the extensions rule. When set, a package's import of its own subpath export (e.g. pkg/sub from inside pkg) is treated as a package import, so ignorePackages applies to it.

• #403 f4d0a4b Thanks @​Zamiell! - extensions: when an import has no extension and cannot be resolved as-is, try the extensions configured as always in pattern and use the unique one that resolves for the fix or suggestion. If several resolve, report the missing extension without guessing. When no extension can be determined automatically, explain that in the missing message instead of only reporting a bare missing extension.

• #572 fc17206 Thanks @​SwastikTripathi! - feat(no-duplicates): add a whitelist option listing entry points that share one declaration file but are different modules, such as svelte and svelte/easing

• #504 f10dcc4 Thanks @​morgan-coded! - Add a "top" mode to the order rule's warnOnUnassignedImports option for requiring no-specifier ESM imports before assigned imports.

• #502 9c85ced Thanks @​SukkaW! - Rewrite the module analysis core for performance boosts. The speedup depends on your project, and we expect no performance regression in any setup — if you measure one, please report it.

  Rules like named, default, namespace, no-cycle, no-deprecated, and many more, need to know what the modules you import actually export. Until now, answering that meant running the full ESLint parser over every one of those files — including everything you pull in from node_modules.

  That core has been rewritten:

  • Plain JavaScript is now read with es-module-lexer instead of being parsed. Anything it can't read faithfully — TypeScript, JSX, Flow — still goes through the ESLint parser exactly as before.
  • Analysis is lazy. Much of the work now happens when a rule actually asks for it, so enabling one rule no longer pays for what the others would have needed.
  • Results are cached and shared between rules.

  There are no breaking changes: no configuration changes are needed, and no behavior changes are intended. Every rule should report exactly what it reported before, with one known exception: an imported plain JavaScript file that has a syntax error no longer gets a "Parse errors in imported module" report. ESLint still reports the syntax error when it lints that file itself. The full test suite passes, but there could be some edge cases. If a rule starts reporting something it didn't before, or stops reporting something it should, please open an issue with a minimum reproduction — bug reports on this are very welcome.

• #456 7b78aae Thanks @​43081j! - Add four barrel file detection rules ported from eslint-plugin-barrel-files: avoid-barrel-files, avoid-importing-barrel-files, avoid-namespace-import and avoid-re-export-all.

  avoid-importing-barrel-files checks every runtime way a module can be referenced — static imports, re-exports (export … from, export * from, export * as ns from), dynamic import() and CommonJS require() — with type-only statements exempt.

• #157 89cfe42 Thanks @​Zamiell! - feat(no-rename-default): accept names derived from bare package paths and add a whitelist option for modules that mangle their default export names

Patch Changes

• #562 7cbe683 Thanks @​JounQin! - perf(avoid-importing-barrel-files): skip the surface parse for a dependency that cannot be a barrel

  The rule sizes the runtime module graph behind every imported target, and a target only becomes a candidate once its export count passes amountOfExportsToConsiderModuleAsBarrel. A lexer-analyzed module already reports its export entries, so a count at or below the threshold settles the question without producing the exact export/declaration surface — one parse saved per small plain-JS dependency.

  Anything es-module-lexer does not read faithfully still goes through the parser, and a module whose source declares a default export is never ruled out: the properties of export default { … } are exports no entry count can see (a default that esModuleInterop synthesizes does not count).

  A declarator that binds no name — export const {} = obj, export const { a: {} } = obj — is no longer counted as an export by the barrel surface: it exports nothing, and counting it made the surface disagree with the lexer's entry count.

• #568 225a5aa Thanks @​SwastikTripathi! - Fix no-extraneous-dependencies telling you to add a package that is already in devDependencies or optionalDependencies when its import resolves through @types/*

... (truncated)

Changelog

Sourced from eslint-plugin-import-x's changelog.

4.18.0

Minor Changes

• #520 802441c Thanks @​SwastikTripathi! - Add a checkSelfReference option to the extensions rule. When set, a package's import of its own subpath export (e.g. pkg/sub from inside pkg) is treated as a package import, so ignorePackages applies to it.

• #403 f4d0a4b Thanks @​Zamiell! - extensions: when an import has no extension and cannot be resolved as-is, try the extensions configured as always in pattern and use the unique one that resolves for the fix or suggestion. If several resolve, report the missing extension without guessing. When no extension can be determined automatically, explain that in the missing message instead of only reporting a bare missing extension.

• #572 fc17206 Thanks @​SwastikTripathi! - feat(no-duplicates): add a whitelist option listing entry points that share one declaration file but are different modules, such as svelte and svelte/easing

• #504 f10dcc4 Thanks @​morgan-coded! - Add a "top" mode to the order rule's warnOnUnassignedImports option for requiring no-specifier ESM imports before assigned imports.

• #502 9c85ced Thanks @​SukkaW! - Rewrite the module analysis core for performance boosts. The speedup depends on your project, and we expect no performance regression in any setup — if you measure one, please report it.

  Rules like named, default, namespace, no-cycle, no-deprecated, and many more, need to know what the modules you import actually export. Until now, answering that meant running the full ESLint parser over every one of those files — including everything you pull in from node_modules.

  That core has been rewritten:

  • Plain JavaScript is now read with es-module-lexer instead of being parsed. Anything it can't read faithfully — TypeScript, JSX, Flow — still goes through the ESLint parser exactly as before.
  • Analysis is lazy. Much of the work now happens when a rule actually asks for it, so enabling one rule no longer pays for what the others would have needed.
  • Results are cached and shared between rules.

  There are no breaking changes: no configuration changes are needed, and no behavior changes are intended. Every rule should report exactly what it reported before, with one known exception: an imported plain JavaScript file that has a syntax error no longer gets a "Parse errors in imported module" report. ESLint still reports the syntax error when it lints that file itself. The full test suite passes, but there could be some edge cases. If a rule starts reporting something it didn't before, or stops reporting something it should, please open an issue with a minimum reproduction — bug reports on this are very welcome.

• #456 7b78aae Thanks @​43081j! - Add four barrel file detection rules ported from eslint-plugin-barrel-files: avoid-barrel-files, avoid-importing-barrel-files, avoid-namespace-import and avoid-re-export-all.

  avoid-importing-barrel-files checks every runtime way a module can be referenced — static imports, re-exports (export … from, export * from, export * as ns from), dynamic import() and CommonJS require() — with type-only statements exempt.

• #157 89cfe42 Thanks @​Zamiell! - feat(no-rename-default): accept names derived from bare package paths and add a whitelist option for modules that mangle their default export names

Patch Changes

• #562 7cbe683 Thanks @​JounQin! - perf(avoid-importing-barrel-files): skip the surface parse for a dependency that cannot be a barrel

  The rule sizes the runtime module graph behind every imported target, and a target only becomes a candidate once its export count passes amountOfExportsToConsiderModuleAsBarrel. A lexer-analyzed module already reports its export entries, so a count at or below the threshold settles the question without producing the exact export/declaration surface — one parse saved per small plain-JS dependency.

  Anything es-module-lexer does not read faithfully still goes through the parser, and a module whose source declares a default export is never ruled out: the properties of export default { … } are exports no entry count can see (a default that esModuleInterop synthesizes does not count).

  A declarator that binds no name — export const {} = obj, export const { a: {} } = obj — is no longer counted as an export by the barrel surface: it exports nothing, and counting it made the surface disagree with the lexer's entry count.

... (truncated)

Commits

• eb711a1 chore: release eslint-plugin-import-x (#514)
• 89cfe42 feat(no-rename-default): recognize package/path names and add a whitelist opt...
• fc17206 feat(no-duplicates): add a whitelist option for packages sharing a declaratio...
• 4afef66 fix(no-relative-packages): keep the imported path in the suggested package im...
• 0c82c7e fix(extensions): point directory imports at their index file in fixes (#594)
• 9144c94 fix(order): move all out of order imports of a block in one fix (#593)
• 7254048 fix: support minimatch v9/v10/v11 and drop makeRe (#570)
• 47c5419 fix(no-namespace): handle members named like Object.prototype ones in the aut...
• b2afa70 fix(namespace): don't check heritage clauses against JavaScript modules (#567)
• 57729ae fix(prefer-namespace-import): keep a namespace specifier when splitting the d...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)