eslint-plugin-import-x

All resolvers must return an object indicating if the module was found and, if applicable, its location. The first resolver to return { found: true } is treated as the source of truth.

Return Object Schema

• found (boolean): true if the source module can be resolved relative to file, otherwise false.
• path (string | null):
  • An absolute path string if the module is located on the filesystem.
  • null if the module is a core/built-in module (e.g., fs or crypto) that can be resolved but does not have a specific file path the plugin needs to parse.

If found is false, the path key is not required.

Do not use this rule if:

• You do not care whether named imports are used.
• You prefer named imports over default imports in your codebase.

The import-x/export rule detects conflicting or redundant export declarations within a single module. It specifically reports:

• Multiple default exports: Attempting to export a default value more than once.
• Duplicate named exports: Exporting the same identifier name multiple times (e.g., using both a declaration and an explicit export object).
• Ambiguous re-exports: When multiple re-exports target the same name, the rule reports all of them because it cannot determine which one is the intended export.

This rule is included in the following configurations:

• errors
• flat/errors
• flat/recommended
• recommended

// Example: Multiple default exports
export default class MyClass { /*...*/ }

function makeClass() { return new MyClass(...arguments) }
export default makeClass // Error: Multiple default exports.

Avoid using this rule if:

• You do not have a preference against default imports.
• You explicitly prefer using default imports over named imports in your codebase.

The import-x/group-exports rule ensures that all exports of a module are consolidated into a single declaration. This makes it easier to identify the public API of a file at a glance.

It reports two main types of violations:

1. Multiple named export declarations: Using multiple export statements for variables or types in a single file.
2. Multiple CommonJS assignments: Performing multiple assignments to module.exports or the exports object in a single file.

Rationale: By requiring a single export declaration, all exports remain in one place, improving code readability and discoverability.

When unusedExports: true is set, the rule reports exports that are not used by any other module in the project via static imports.

Key Behaviors:

• export * behavior: Using export * from 'module' only considers named exports and ignores the default export of the source module.
• Package Entry Points: Exports from files listed as main, browser, or bin in package.json are ignored by default, unless the package is marked as private: true in package.json.

// file-a.js
export const a = 1 // Reported if not used elsewhere
export { b, c }      // Not reported if used elsewhere
export { d as e }     // Not reported if used elsewhere

// file-c.js
export default () => {} // Reported if using 'export *' from file-c

Currently, import-x/no-mutable-exports does not flag the reassignment of exported function or class identifiers.

To prevent general reassignment of these identifiers (both exported and unexported), you should complement this rule with the following core ESLint rules:

• no-func-assign: Prevents assigning values to function identifiers.
• no-class-assign: Prevents assigning values to class identifiers.

If you set allowEmpty: true in the rule configuration, the rule will permit dynamic imports that do not have a webpackChunkName specified. This includes imports with no leading comment at all, or imports with a leading comment that contains other webpack magic comments but lacks a webpackChunkName.

Note: Even with allowEmpty: true, if you do provide a webpackChunkName comment, it must still follow the correct formatting rules. Incorrectly formatted comments will still trigger an error.

// Valid when allowEmpty: true
import('someModule')

// Still invalid even if allowEmpty: true (due to bad formatting)
import(
  /*webpackChunkName:"someModule"*/
  'someModule'
)

The import-x/default rule ensures that when you attempt to use a default import, the target module actually provides a default export.

Behavior:

• If you request a default import, the rule reports an error if no default export is found in the module.
• For ES7-style modules, it reports if a default is named and exported but cannot be found in the referenced module.
• For npm packages, the plugin attempts to find exported names via the jsnext:main field in package.json (e.g., Redux supports this).
• Exclusions: Module paths that are [ignored] or are not [unambiguously an ES module] will not be reported.

Included in these configurations:

• errors
• flat/errors
• flat/recommended
• recommended

You can use the except attribute within a zone to allow specific imports that would otherwise be blocked by the from path.

Important constraints:

1. If your from configuration uses glob patterns, your except configuration must also be an array of glob patterns.
2. If your from configuration uses directory paths, your except paths are relative to the from directory and cannot use .. to backtrack to a parent directory.

Example: Directory-based exception

Given a structure where server/one is restricted from being imported into server/one/a.js, but you want to allow imports from a specific sub-folder ./one within that restricted path:

{
  "zones": [
    {
      "target": "./tests/files/restricted-paths/server/one",
      "from": "./tests/files/restricted-paths/server",
      "except": ["./one"]
    }
  ]
}