eslint-plugin-import-x

This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, and prevent issues with misspelling of file paths and import names. All the goodness that the ES2015+ static module syntax intends to provide, marked up in your editor.

eslint-plugin-i is now eslint-plugin-import-x

IF YOU ARE USING THIS WITH SUBLIME: see the bottom section for important info.

Rules

💼 Configurations enabled in.\ ⚠️ Configurations set to warn in.\ 🚫 Configurations disabled in.\ ❗ Set in the errors configuration.\ ☑️ Set in the recommended configuration.\ ⌨️ Set in the typescript configuration.\ 🚸 Set in the warnings configuration.\ 🔧 Automatically fixable by the --fix CLI option.\ 💡 Manually fixable by editor suggestions.\ ❌ Deprecated.

Helpful warnings

Module systems

Static analysis

Style guide

Installation

# inside your project's working tree
npm install eslint-plugin-import-x --save-dev

Configuration (legacy: .eslintrc*)

[!TIP] If your eslint is >=8.23.0, you're 100% ready to use the new config system. See dedicated section below.

[!NOTE] All rules are off by default. However, you may configure them manually in your .eslintrc.(yml|json|js), or extend one of the canned configs:

---
extends:
  - eslint:recommended
  - plugin:import-x/recommended
  # alternatively, 'recommended' is the combination of these two rule sets:
  - plugin:import-x/errors
  - plugin:import-x/warnings

# or configure manually:
plugins:
  - import-x

rules:
  import-x/no-unresolved: [2, { commonjs: true, amd: true }]
  import-x/named: 2
  import-x/namespace: 2
  import-x/default: 2
  import-x/export: 2
  # etc...

TypeScript

You may use the following snippet or assemble your own config using the granular settings described below it.

[!WARNING] Make sure you have installed @typescript-eslint/parser and eslint-import-resolver-typescript which are used in the following configuration.

extends:
  - eslint:recommended
  - plugin:import-x/recommended
  # the following lines do the trick
  - plugin:import-x/typescript
settings:
  import-x/resolver:
    # You will also need to install and configure the TypeScript resolver
    # See also https://github.com/import-js/eslint-import-resolver-typescript#configuration
    typescript: true
    node: true

Configuration (new: eslint.config.js)

From v8.21.0, ESLint announced a new config system. In the new system, .eslintrc* is no longer used. eslint.config.js would be the default config file name.

import js from '@eslint/js'
import eslintPluginImportX from 'eslint-plugin-import-x'

export default [
  js.configs.recommended,
  eslintPluginImportX.flatConfigs.recommended,
]

npm install eslint-import-resolver-typescript --save-dev

import js from '@eslint/js'
import eslintPluginImportX from 'eslint-plugin-import-x'
import tsParser from '@typescript-eslint/parser'

export default [
  js.configs.recommended,
  eslintPluginImportX.flatConfigs.recommended,
  eslintPluginImportX.flatConfigs.typescript,
  {
    files: ['**/*.{js,mjs,cjs,jsx,mjsx,ts,tsx,mtsx}'],
    ignores: ['eslint.config.js'],
    languageOptions: {
      parser: tsParser,
      ecmaVersion: 'latest',
      sourceType: 'module',
    },
    rules: {
      'no-unused-vars': 'off',
      'import-x/no-dynamic-require': 'warn',
      'import-x/no-nodejs-modules': 'warn',
    },
  },
]

[!NOTE] A complete list of available configuration can be found in config/flat folders

Resolvers

With the advent of module bundlers and the current state of modules and module syntax specs, it's not always obvious where import x from 'module' should look to find the file behind module.

Up through v0.10ish, this plugin has directly used substack's resolve plugin, which implements Node's import behavior. This works pretty well in most cases.

However, webpack allows a number of things in import module source strings that Node does not, such as loaders (import 'file!./whatever') and a number of aliasing schemes, such as externals: mapping a module id to a global name at runtime (allowing some modules to be included more traditionally via script tags).

In the interest of supporting both of these, v0.11 introduces resolvers.

Currently Node and webpack resolution have been implemented, but the resolvers are just npm packages, so third party packages are supported (and encouraged!).

You can reference resolvers in several ways (in order of precedence):

• as a conventional eslint-import-resolver name, like eslint-import-resolver-foo:

# .eslintrc.yml
settings:
  # uses 'eslint-import-resolver-foo':
  import-x/resolver: foo

// .eslintrc.js
module.exports = {
  settings: {
    'import-x/resolver': {
      foo: { someConfig: value },
    },
  },
}

• with a full npm module name, like my-awesome-npm-module:

# .eslintrc.yml
settings:
  import-x/resolver: 'my-awesome-npm-module'

// .eslintrc.js
module.exports = {
  settings: {
    'import-x/resolver': {
      'my-awesome-npm-module': { someConfig: value },
    },
  },
}

• with a filesystem path to resolver, defined in this example as a computed property name:

// .eslintrc.js
module.exports = {
  settings: {
    'import-x/resolver': {
      [path.resolve('../../../my-resolver')]: { someConfig: value },
    },
  },
}

• use the import or require syntax to directly import the resolver object:

// .eslintrc.mjs
import tsResolver from 'eslint-import-resolver-typescript'

export default {
  settings: {
    'import-x/resolver': {
      name: 'tsResolver', // required, could be any string you like
      // enable: false, // optional, defaults to true
      options: { someConfig: value }, // optional, options to pass to the resolver
      resolver: tsResolver, // required, the resolver object
    },
  },
}

// .eslintrc.cjs
const tsResolver = require('eslint-import-resolver-typescript')

module.exports = {
  settings: {
    'import-x/resolver': {
      name: 'tsResolver', // required, could be any string you like
      // enable: false, // optional, defaults to true
      options: { someConfig: value }, // optional, options to pass to the resolver
      resolver: tsResolver, // required, the resolver object
    },
  },
}

Relative paths will be resolved relative to the source's nearest package.json or the process's current working directory if no package.json is found.

If you are interesting in writing a resolver, see the spec for more details.

Settings

You may set the following settings in your .eslintrc:

import-x/extensions

A list of file extensions that will be parsed as modules and inspected for exports.

This defaults to ['.js'], unless you are using the react shared config, in which case it is specified as ['.js', '.jsx']. Despite the default, if you are using TypeScript (without the plugin:import-x/typescript config described above) you must specify the new extensions (.ts, and also .tsx if using React).

"settings": {
  "import-x/extensions": [
    ".js",
    ".jsx"
  ]
}

If you require more granular extension definitions, you can use:

"settings": {
  "import-x/resolver": {
    "node": {
      "extensions": [
        ".js",
        ".jsx"
      ]
    }
  }
}

Note that this is different from (and likely a subset of) any import-x/resolver extensions settings, which may include .json, .coffee, etc. which will still factor into the no-unresolved rule.

Also, the following import-x/ignore patterns will overrule this list.

import-x/ignore

A list of regex strings that, if matched by a path, will not report the matching module if no exports are found. In practice, this means rules other than no-unresolved will not report on any imports with (absolute filesystem) paths matching this pattern.

no-unresolved has its own ignore setting.

settings:
  import-x/ignore:
    - \.coffee$ # fraught with parse errors
    - \.(scss|less|css)$ # can't parse unprocessed CSS modules, either

import-x/core-modules

An array of additional modules to consider as "core" modules--modules that should be considered resolved but have no path on the filesystem. Your resolver may already define some of these (for example, the Node resolver knows about fs and path), so you need not redefine those.

For example, Electron exposes an electron module:

import 'electron' // without extra config, will be flagged as unresolved!

that would otherwise be unresolved. To avoid this, you may provide electron as a core module:

# .eslintrc.yml
settings:
  import-x/core-modules: [electron]

In Electron's specific case, there is a shared config named electron that specifies this for you.

Contribution of more such shared configs for other platforms are welcome!

import-x/external-module-folders

An array of folders. Resolved modules only from those folders will be considered as "external". By default - ["node_modules"]. Makes sense if you have configured your path or webpack to handle your internal paths differently and want to consider modules from some folders, for example bower_components or jspm_modules, as "external".

This option is also useful in a monorepo setup: list here all directories that contain monorepo's packages and they will be treated as external ones no matter which resolver is used.

If you are using yarn PnP as your package manager, add the .yarn folder and all your installed dependencies will be considered as external, instead of internal.

Each item in this array is either a folder's name, its subpath, or its absolute prefix path:

• jspm_modules will match any file or folder named jspm_modules or which has a direct or non-direct parent named jspm_modules, e.g. /home/me/project/jspm_modules or /home/me/project/jspm_modules/some-pkg/index.js.

• packages/core will match any path that contains these two segments, for example /home/me/project/packages/core/src/utils.js.

• /home/me/project/packages will only match files and directories inside this directory, and the directory itself.

Please note that incomplete names are not allowed here so components won't match bower_components and packages/ui won't match packages/ui-utils (but will match packages/ui/utils).

import-x/parsers

A map from parsers to file extension arrays. If a file extension is matched, the dependency parser will require and use the map key as the parser instead of the configured ESLint parser. This is useful if you're inter-op-ing with TypeScript directly using webpack, for example:

# .eslintrc.yml
settings:
  import-x/parsers:
    '@typescript-eslint/parser': [.ts, .tsx]

In this case, @typescript-eslint/parser must be installed and require-able from the running eslint module's location (i.e., install it as a peer of ESLint).

This is currently only tested with @typescript-eslint/parser (and its predecessor, typescript-eslint-parser) but should theoretically work with any moderately ESTree-compliant parser.

It's difficult to say how well various plugin features will be supported, too, depending on how far down the rabbit hole goes. Submit an issue if you find strange behavior beyond here, but steel your heart against the likely outcome of closing with wontfix.

import-x/resolver

See resolvers.

import-x/cache

Settings for cache behavior. Memoization is used at various levels to avoid the copious amount of fs.statSync/module parse calls required to correctly report errors.

For normal eslint console runs, the cache lifetime is irrelevant, as we can strongly assume that files should not be changing during the lifetime of the linter process (and thus, the cache in memory)

For long-lasting processes, like eslint_d or eslint-loader, however, it's important that there be some notion of staleness.

If you never use eslint_d or eslint-loader, you may set the cache lifetime to Infinity and everything should be fine:

# .eslintrc.yml
settings:
  import-x/cache:
    lifetime: ∞ # or Infinity

Otherwise, set some integer, and cache entries will be evicted after that many seconds have elapsed:

# .eslintrc.yml
settings:
  import-x/cache:
    lifetime: 5 # 30 is the default

import-x/internal-regex

A regex for packages should be treated as internal. Useful when you are utilizing a monorepo setup or developing a set of packages that depend on each other.

By default, any package referenced from import-x/external-module-folders will be considered as "external", including packages in a monorepo like yarn workspace or lerna environment. If you want to mark these packages as "internal" this will be useful.

For example, if your packages in a monorepo are all in @scope, you can configure import-x/internal-regex like this

# .eslintrc.yml
settings:
  import-x/internal-regex: ^@scope/

SublimeLinter-eslint

SublimeLinter-eslint introduced a change to support .eslintignore files which altered the way file paths are passed to ESLint when linting during editing. This change sends a relative path instead of the absolute path to the file (as ESLint normally provides), which can make it impossible for this plugin to resolve dependencies on the filesystem.

This workaround should no longer be necessary with the release of ESLint 2.0, when .eslintignore will be updated to work more like a .gitignore, which should support proper ignoring of absolute paths via --stdin-filename.

In the meantime, see roadhump/SublimeLinter-eslint#58 for more details and discussion, but essentially, you may find you need to add the following SublimeLinter config to your Sublime project file:

{
  "folders": [
    {
      "path": "code"
    }
  ],
  "SublimeLinter": {
    "linters": {
      "eslint": {
        "chdir": "${project}/code"
      }
    }
  }
}

Note that ${project}/code matches the code provided at folders[0].path.

The purpose of the chdir setting, in this case, is to set the working directory from which ESLint is executed to be the same as the directory on which SublimeLinter-eslint bases the relative path it provides.

See the SublimeLinter docs on chdir for more information, in case this does not work with your project.

If you are not using .eslintignore, or don't have a Sublime project file, you can also do the following via a .sublimelinterrc file in some ancestor directory of your code:

{
  "linters": {
    "eslint": {
      "args": ["--stdin-filename", "@"]
    }
  }
}

I also found that I needed to set rc_search_limit to null, which removes the file hierarchy search limit when looking up the directory tree for .sublimelinterrc:

In Package Settings / SublimeLinter / User Settings:

{
  "user": {
    "rc_search_limit": null
  }
}

I believe this defaults to 3, so you may not need to alter it depending on your project folder max depth.

eslint-plugin-import-x

4.6.1

Patch Changes

• #211 be9c3e8 Thanks @mrginglymus! - Fix enhanced-resolve dependency

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

• #206 449738f Thanks @privatenumber! - insert type prefix without new line

4.5.1

Patch Changes

• #198 ac6d2e1 Thanks @voxpelli! - Fix #197 with missing types

• #204 32e9b55 Thanks @privatenumber! - fix type-import and value-import merging when import-as is used

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/types.

  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

• #175 acebd98 Thanks @marcalexiei! - fix(extensions): correct Options type

• #174 e01dce0 Thanks @marcalexiei! - fix(no-extraneous-dependencies): correct some Options type properties

4.4.0

Minor Changes

• #169 9c58269 Thanks @teidesu! - Add new rule option checkTypedImports for extensions, backports https://github.com/import-js/eslint-plugin-import/pull/2817

Patch Changes

• #171 9715220 Thanks @SukkaW! - Perf: avoid regexp during parser choosing

• #171 9715220 Thanks @SukkaW! - Add extra guard for rule no-named-as-default. A few guards are borrowed from https://github.com/import-js/eslint-plugin-import/pull/3032, but we don't sync the rest of changes from upstream since we have already implemented a way more performant check.

• #171 9715220 Thanks @SukkaW! - More test cases for no-named-export and no-defualt-export rule specifically with non-module sourceType

• #171 9715220 Thanks @SukkaW! - Fix export when there is only one TSDeclareFunction (https://github.com/import-js/eslint-plugin-import/pull/3065)

• #171 9715220 Thanks @SukkaW! - Prevent ExportMap's cache is being tainted by incompatible parser (e.g. old babel-eslint). The cache is now skipped w/ incompatible parsers, which might introduce performance impacts only for those who are using incompatible parsers. (https://github.com/import-js/eslint-plugin-import/pull/3062)

• #171 9715220 Thanks @SukkaW! - Docs: fix a few typos here and there

• #168 5de039c Thanks @hyoban! - Fixes https://github.com/un-ts/eslint-plugin-import-x/issues/167, the no-duplicates rule now allows co-existing inline type imports and namespace imports.

• #171 9715220 Thanks @SukkaW! - Properly fix espree parser w/ ESLint Flat Config

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

• #159 4da5388 Thanks @GoodbyeNJN! - feat: add support for using resolver object directly in settings

4.2.1

Patch Changes

• #148 d228129 Thanks @SukkaW! - Fix newline-after-import's considerComments options when linting require, backports https://github.com/import-js/eslint-plugin-import/pull/2952

• #147 eca73ed Thanks @nchevsky! - Fix regression in rule no-unused-modules which would incorrectly initialize option src to [] instead of [process.cwd()], breaking file discovery.

• #148 d228129 Thanks @SukkaW! - Fix no-duplicates for TypeScript, backports https://github.com/import-js/eslint-plugin-import/pull/3033

4.2.0

Minor Changes

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

Patch Changes

• #146 e5e4580 Thanks @SukkaW! - Fix https://github.com/nuxt/eslint/issues/494 by avoid importing from @typescript-eslint/typescript-estree.

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

• #116 38aa4cb Thanks @silverwind! - Add ignoreUnusedTypeExports option to no-unused-modules

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

• #109 fe3121a Thanks @SukkaW! - Make eslint-plugin-import-x overall faster by refactoring the ExportMap util

• #111 5cce946 Thanks @SukkaW! - Drastically improve no-cycle's performance by skipping unnecessary BFSes using Tarjan's SCC.

• #109 fe3121a Thanks @SukkaW! - Make no-cycle rule faster

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

• #104 2d45869 Thanks @SukkaW! - Make no-duplicates way faster

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

• #82 e29ba7f Thanks @unzico! - fix: cannot find module 'tslib'

0.5.0

Minor Changes

• #66 49418a0 Thanks @JounQin! - chore(dep)!: drop eslint <8.56 support

• #66 49418a0 Thanks @JounQin! - feat!: upgrade @typescript-eslint/utils to v7

0.4.4

Patch Changes

• #67 7a6145c Thanks @JounQin! - fix: only add dependencies when no exported found

0.4.3

Patch Changes

• #64 b858aee Thanks @JounQin! - fix(export-map): incorrect internal namespaces info

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

• #56 843cf49 Thanks @JounQin! - fix: known compatibility issues

0.4.0

Minor Changes

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

0.3.1

Patch Changes

• #51 f4ca4b5 Thanks @JounQin! - refactor: migrate all remaining rules

• #48 3d7a551 Thanks @JounQin! - refactor: migrate more rules

• #50 de896f4 Thanks @JounQin! - refactor: migrate several rules

0.3.0

Minor Changes

• #42 6ee88e8 Thanks @JounQin! - feat!: start TypeScript migration

Patch Changes

• #44 bbf46c3 Thanks @JounQin! - feat: migrate named rule and related usage

• #45 dc3d48b Thanks @JounQin! - refactor: migrate core utils

0.2.0

Minor Changes

• #38 3a5dab4 Thanks @JounQin! - chore!: bump all upgradable (dev)Dependencies

• #36 49e3cd2 Thanks @JounQin! - feat!: replace tsconfig-paths with get-tsconfig

Patch Changes

• #39 d0d36de Thanks @JounQin! - docs: update repository url

0.1.1

Patch Changes

• #34 a615826 Thanks @JounQin! - chore: cleanup npm package content

0.1.0

Minor Changes

• #32 46ee54d Thanks @JounQin! - feat!: cleanup deps, remove unnecessary ponyfills