eslint-plugin-import-x

March 11, 2026 · View on GitHub

4.16.2

Patch Changes

  • #457 1da4043 Thanks @SukkaW! - Make the no-unused-modules rule no-op on ESLint 10 or later for now before we can implement an alternative. A warning message about this behavior is added, and can be suppressed with the new suppressMissingFileEnumeratorAPIWarning rule option (import-x/no-unused-modules: ['error', { suppressMissingFileEnumeratorAPIWarning: true }]).

  • #450 a51be0f Thanks @andrewgaun! - fix(deps): Bumping minimatch 10 version to avoid dependency with a critical vulnerability

    Updating the minimum minimatch 10 version to 10.1.2 which updates a dependency (@isaacs/brace-expansion) with a critical vulnerability. See https://github.com/advisories/GHSA-7h2j-956f-4vf2

  • #466 b669aca Thanks @SukkaW! - Make eslint-plugin-import-x compatible with ESLint's defineConfig

  • #434 a3aae61 Thanks @stepankuzmin! - fix(deps): replace type-fest with @package-json/types

    PackageJson types are imported in published declaration files (lib/rules/no-extraneous-dependencies.d.ts and lib/utils/read-pkg-up.d.ts), which causes TypeScript compilation errors for consumers who don't have skipLibCheck enabled. Replacing type-fest with the smaller @package-json/types package ensures the types are available to all consumers while reducing bundle size.

  • #458 60312ee Thanks @SukkaW! - Bump peer deps version range to include ESLint 10 support

  • #443 b416a8a Thanks @baevm! - consistent-type-specifier-style: Add exception for TS resolution-mode import attributes

  • #454 d3f8d67 Thanks @SukkaW! - First step toward ESLint 10 support:

    • sourceType determination now prefers context.languageOptions when possible
    • Ensure context.parserOptions no longer results in crashes with ESLint 10
    • Merge getParser and getParserPath implementations into one getParserOrPath

  • #406 d0a7816 Thanks @marcalexiei! - fix(package): remove config and rules exports pointing to empty files

4.16.1

Patch Changes

4.16.0

Minor Changes

Patch Changes

4.15.2

Patch Changes

4.15.1

Patch Changes

4.15.0

Minor Changes

4.14.2

Patch Changes

4.14.1

Patch Changes

4.14.0

Minor Changes

Patch Changes

  • #352 3bc48fc Thanks @JounQin! - fix: enable nocomment glob option for rule no-unassigned-import's allow option

4.13.3

Patch Changes

  • #348 f949929 Thanks @JounQin! - fix(types): exported importX should also have flatConfigs as property

4.13.2

Patch Changes

4.13.1

Patch Changes

4.13.0

Minor Changes

  • #335 371ebee Thanks @JounQin! - feat: integrate eslint-import-context to get rule context without additional params

4.12.2

Patch Changes

4.12.1

Patch Changes

4.12.0

Minor Changes

4.11.1

Patch Changes

4.11.0

Minor Changes

4.10.6

Patch Changes

4.10.5

Patch Changes

4.10.4

Patch Changes

4.10.3

Patch Changes

  • #292 1342127 Thanks @JounQin! - refactor: remove unnecessary check for pnpapi because unrs-resolver already handles it

4.10.2

Patch Changes

4.10.1

Patch Changes

4.10.0

Minor Changes

Patch Changes

4.9.4

Patch Changes

4.9.3

Patch Changes

  • #263 c0046a9 Thanks @JounQin! - chore: migrate to rebranding unrs-resolver with new targets supported:
    • i686-pc-windows-msvc
    • armv7-unknown-linux-musleabihf
    • powerpc64le-unknown-linux-gnu
    • s390x-unknown-linux-gnu

4.9.2

Patch Changes

4.9.1

Patch Changes

4.9.0

Minor Changes

4.8.1

Patch Changes

4.8.0

Minor Changes

4.7.2

Patch Changes

4.7.1

Patch Changes

4.7.0

Minor Changes

Patch Changes

4.6.1

Patch Changes

4.6.0

Minor Changes

  • #209 46d2360 Thanks @SukkaW! - When eslint-plugin-import-x was forked from eslint-plugin-import, we copied over the default resolver (which is eslint-import-resolver-node) as well. However, this resolver doesn't supports exports in the package.json file, and the current maintainer of the eslint-import-resolver-node (ljharb) doesn't have the time implementing this feature and he locked the issue https://github.com/import-js/eslint-plugin-import/issues/1810.

    So we decided to implement our own resolver that "just works". The new resolver is built upon the enhanced-resolve that implements the full Node.js Resolver Algorithm. The new resolver only implements the import resolver interface v3, which means you can only use it with ESLint Flat config. For more details about the import resolver interface v3, please check out #192.

    In the next major version of eslint-plugin-import-x, we will remove the eslint-import-resolver-node and use this new resolver by default. In the meantime, you can try out this new resolver by setting the import-x/resolver-next option in your eslint.config.js file:

    // eslint.config.js
const eslintPluginImportX = require('eslint-plugin-import-x');
const { createNodeResolver } = eslintPluginImportX;

module.exports = {
  plugins: {
    'import-x': eslintPluginImportX,
  },
  settings: {
    'import-x/resolver-next': [
      // This is the new resolver we are introducing
      createNodeResolver({
        /**
         * The allowed extensions the resolver will attempt to find when resolving a module
         * By default it uses a relaxed extension list to search for both ESM and CJS modules
         * You can customize this list to fit your needs
         *
         * @default ['.mjs', '.cjs', '.js', '.json', '.node']
         */
        extensions?: string[];
        /**
         * Optional, the import conditions the resolver will used when reading the exports map from "package.json"
         * By default it uses a relaxed condition list to search for both ESM and CJS modules
         * You can customize this list to fit your needs
         *
         * @default ['default', 'module', 'import', 'require']
         */
        conditions: ['default', 'module', 'import', 'require'],
        // You can pass more options here, see the enhanced-resolve documentation for more details
        // https://github.com/webpack/enhanced-resolve/tree/v5.17.1?tab=readme-ov-file#resolver-options
      }),
      // you can add more resolvers down below
      require('eslint-import-resolver-typescript').createTypeScriptImportResolver(
        /** options of eslint-import-resolver-typescript */
      )
    ],
  },
};

    We do not plan to implement reading baseUrl and paths from the tsconfig.json file in this resolver. If you need this feature, please checkout eslint-import-resolver-typescript (also powered by enhanced-resolve), eslint-import-resolver-oxc (powered by oxc-resolver), eslint-import-resolver-next (also powered by oxc-resolver), or other similar resolvers.

Patch Changes

4.5.1

Patch Changes

4.5.0

Minor Changes

  • #192 fbf639b Thanks @SukkaW! - The PR implements the new resolver design proposed in https://github.com/un-ts/eslint-plugin-import-x/issues/40#issuecomment-2381444266

    For eslint-plugin-import-x users

    Like the ESLint flat config allows you to use js objects (e.g. import and require) as ESLint plugins, the new eslint-plugin-import-x resolver settings allow you to use js objects as custom resolvers through the new setting import-x/resolver-next:

    // eslint.config.js
import { createTsResolver } from '#custom-resolver';
const { createOxcResolver } = require('path/to/a/custom/resolver');

const resolverInstance = new ResolverFactory({});
const customResolverObject = {
  interfaceVersion: 3,
  name: 'my-custom-eslint-import-resolver',
  resolve(modPath, sourcePath) {
    const path = resolverInstance.resolve(modPath, sourcePath);
    if (path) {
      return {
        found: true,
        path
      };
    }

    return {
      found: false,
      path: null
    }
  };
};

module.exports = {
  settings: {
    // multiple resolvers
    'import-x/resolver-next': [
      customResolverObject,
      createTsResolver(enhancedResolverOptions),
      createOxcResolver(oxcOptions),
    ],
    // single resolver:
    'import-x/resolver-next': [createOxcResolver(oxcOptions)]
  }
}

    The new import-x/resolver-next no longer accepts strings as the resolver, thus will not be compatible with the ESLint legacy config (a.k.a. .eslintrc). Those who are still using the ESLint legacy config should stick with import-x/resolver.

    In the next major version of eslint-plugin-import-x (v5), we will rename the currently existing import-x/resolver to import-x/resolver-legacy (which allows the existing ESLint legacy config users to use their existing resolver settings), and import-x/resolver-next will become the new import-x/resolver. When ESLint v9 (the last ESLint version with ESLint legacy config support) reaches EOL in the future, we will remove import-x/resolver-legacy.

    We have also made a few breaking changes to the new resolver API design, so you can't use existing custom resolvers directly with import-x/resolver-next:

    // When migrating to `import-x/resolver-next`, you CAN'T use legacy versions of resolvers directly:
module.exports = {
  settings: {
    // THIS WON'T WORK, the resolver interface required for `import-x/resolver-next` is different.
    'import-x/resolver-next': [
       require('eslint-import-resolver-node'),
       require('eslint-import-resolver-webpack'),
       require('some-custom-resolver')
    ];
  }
}

    For easier migration, the PR also introduces a compat utility importXResolverCompat that you can use in your eslint.config.js:

    // eslint.config.js
import eslintPluginImportX, { importXResolverCompat } from 'eslint-plugin-import-x';
// or
const eslintPluginImportX = require('eslint-plugin-import-x');
const { importXResolverCompat } = eslintPluginImportX;

module.exports = {
  settings: {
    // THIS WILL WORK as you have wrapped the previous version of resolvers with the `importXResolverCompat`
    'import-x/resolver-next': [
       importXResolverCompat(require('eslint-import-resolver-node'), nodeResolveOptions),
       importXResolverCompat(require('eslint-import-resolver-webpack'), webpackResolveOptions),
       importXResolverCompat(require('some-custom-resolver'), { option1: true, option2: '' })
    ];
  }
}

    For custom import resolver developers

    This is the new API design of the resolver interface:

    export interface NewResolver {
  interfaceVersion: 3
  name?: string // This will be included in the debug log
  resolve: (modulePath: string, sourceFile: string) => ResolvedResult
}

// The `ResultNotFound` (returned when not resolved) is the same, no changes
export interface ResultNotFound {
  found: false
  path?: undefined
}

// The `ResultFound` (returned resolve result) is also the same, no changes
export interface ResultFound {
  found: true
  path: string | null
}

export type ResolvedResult = ResultNotFound | ResultFound

    You will be able to import NewResolver from eslint-plugin-import-x.

    The most notable change is that eslint-plugin-import-x no longer passes the third argument (options) to the resolve function.

    We encourage custom resolvers' authors to consume the options outside the actual resolve function implementation. You can export a factory function to accept the options, this factory function will then be called inside the eslint.config.js to get the actual resolver:

    // custom-resolver.js
exports.createCustomResolver = (options) => {
  // The options are consumed outside the `resolve` function.
  const resolverInstance = new ResolverFactory(options);

  return {
    name: 'custom-resolver',
    interfaceVersion: 3,
    resolve(mod, source) {
      const found = resolverInstance.resolve(mod, {});

      // Of course, you still have access to the `options` variable here inside
      // the `resolve` function. That's the power of JavaScript Closures~
    }
  }
};

// eslint.config.js
const { createCustomResolver } = require('custom-resolver')

module.exports = {
  settings: {
    'import-x/resolver-next': [
       createCustomResolver(options)
    ];
  }
}

    This allows you to create a reusable resolver instance to improve the performance. With the existing version of the resolver interface, because the options are passed to the resolver function, you will have to create a resolver instance every time the resolve function is called:

    module.exports = {
  interfaceVersion: 2,
  resolve(mod, source) {
    // every time the `resolve` function is called, a new instance is created
    // This is very slow
    const resolverInstance = ResolverFactory.createResolver({})
    const found = resolverInstance.resolve(mod, {})
  },
}

    With the factory function pattern, you can create a resolver instance beforehand:

    exports.createCustomResolver = options => {
  // `enhance-resolve` allows you to create a reusable instance:
  const resolverInstance = ResolverFactory.createResolver({})
  const resolverInstance = enhanceResolve.create({})

  // `oxc-resolver` also allows you to create a reusable instance:
  const resolverInstance = new ResolverFactory({})

  return {
    name: 'custom-resolver',
    interfaceVersion: 3,
    resolve(mod, source) {
      // the same re-usable instance is shared across `resolve` invocations.
      // more performant
      const found = resolverInstance.resolve(mod, {})
    },
  }
}

Patch Changes

  • #184 bc4de89 Thanks @marcalexiei! - fix(no-cycle): improves the type declaration of the rule no-cycle’s maxDepth option

  • #184 bc4de89 Thanks @marcalexiei! - fix(first): improves the type declaration of the rule first's option

  • #184 bc4de89 Thanks @marcalexiei! - fix(no-unused-modules): improves the type declaration of the rule no-unused-modules’s missingExports option

  • #184 bc4de89 Thanks @marcalexiei! - fix(no-deprecated): improve error message when no description is available

4.4.3

Patch Changes

  • #187 a428f82 Thanks @SukkaW! - Attach ecmaVersion and sourceType to parserOptions during parse

4.4.2

Patch Changes

  • #181 cc4ee65 Thanks @SukkaW! - Fix #144, read proper sourceType for both eslint flat config and legacy eslintrc config.

4.4.1

Patch Changes

4.4.0

Minor Changes

Patch Changes

4.3.1

Patch Changes

  • #162 38d0081 Thanks @AaronMoat! - Fix issue where no-duplicates rule with prefer-inline incorrectly marks default type and named type imports as duplicates

4.3.0

Minor Changes

4.2.1

Patch Changes

4.2.0

Minor Changes

  • #142 f12447e Thanks @Zamiell! - Add new option "whitelist" for rule "no-extraneous-dependencies"

Patch Changes

4.1.1

Patch Changes

  • #133 757ffa9 Thanks @SukkaW! - Fix #123 where the rule no-named-as-default will confuse TypeScript namespace exports with actual exports.

4.1.0

Minor Changes

  • #122 cd52e86 Thanks @michaelfaith! - Add ESLint flat configuration presets. You can access them with:

    import eslintPluginImportX from 'eslint-plugin-import-x'

eslintPluginImportX.flatConfigs.recommended
eslintPluginImportX.flatConfigs.react
eslintPluginImportX.flatConfigs.typescript
eslintPluginImportX.flatConfigs.electron

  • #132 9948c78 Thanks @SukkaW! - Added no-rename-default that forbid importing a default export by a different name. Originally created by @whitneyit, ported by @SukkaW

4.0.0

Major Changes

  • #112 4ba14da Thanks @SukkaW! - Use typescript-eslint v8. The minimum supported ESLint version is now >= 8.57.0 and the minimum required Node.js version is now 18.18.0.

3.1.0

Minor Changes

Patch Changes

  • #118 0307ff2 Thanks @SukkaW! - Reverts #111. The introduction of SCC causes extra overhead that overcomes the early return it introduced.

    A new no-cycle-next rule is being implemented using the graph. It won't be backward compatible with the current rule no-cycle. The current no-cycle rule will become no-cycle-legacy in the next major version.

3.0.1

Patch Changes

3.0.0

Major Changes

  • #106 19f10aa Thanks @SukkaW! - eslint-plugin-import-x is a fork of eslint-plugin-import that aims to provide a more performant and more lightweight version of the original plugin.

    Due to the nature of the fork, all eslint-plugin-import's git tags and releases have been copied over to eslint-plugin-import-x. This causes version conflicts when publishing new versions of eslint-plugin-import-x.

    To prevent this, we have decided to publish a new major version of eslint-plugin-import-x that will not conflict with the original eslint-plugin-import's versions.

    See also https://github.com/un-ts/eslint-plugin-import-x/issues/76

Patch Changes

0.5.3

Patch Changes

  • #101 c0cea7b Thanks @SukkaW! - Allow incorrect file path in extraneous deps check

  • #100 293fcf4 Thanks @SukkaW! - feat: webpack comment regex support webpackFetchPriority

  • #85 ded3e80 Thanks @kosmotema! - add languageOptions to ChildContext

  • #100 293fcf4 Thanks @SukkaW! - Allow empty chunk name when webpackMode: 'eager' is set; add suggestions to remove name in eager mode

0.5.2

Patch Changes

  • #93 64bf1a6 Thanks @SukkaW! - fix: enable isolation parsing w/ typescript-eslint v8

0.5.1

Patch Changes

0.5.0

Minor Changes

0.4.4

Patch Changes

0.4.3

Patch Changes

0.4.2

Patch Changes

  • #62 1dbb323 Thanks @JounQin! - feat: use eslint-compat-utils to support eslint v9 (not flat config yet)

0.4.1

Patch Changes

0.4.0

Minor Changes

  • #54 54d0c95 Thanks @JounQin! - chore!: bump node requirement (>=16), enable more lint rules

0.3.1

Patch Changes

0.3.0

Minor Changes

Patch Changes

0.2.0

Minor Changes

Patch Changes

0.1.1

Patch Changes

0.1.0

Minor Changes