eslint-import-resolver-typescript

What is eslint-import-resolver-typescript?

The eslint-import-resolver-typescript package is a plugin for ESLint that helps in resolving import paths for TypeScript files. It allows ESLint to understand TypeScript syntax and resolve paths according to the TypeScript compiler options. This is particularly useful when using features like path aliases and custom module directories in TypeScript projects.

What are eslint-import-resolver-typescript's main functionalities?

Resolving TypeScript Path Aliases

This feature allows the resolver to use TypeScript's path aliases defined in tsconfig.json to resolve modules, which helps ESLint to understand custom path mappings.

module.exports = {
  settings: {
    'import/resolver': {
      typescript: {
        // use <root>/tsconfig.json
        project: '.'
      }
    }
  }
};

Support for Multiple tsconfig Files

The resolver can be configured to use multiple tsconfig.json files, which is useful in monorepos or projects with multiple TypeScript configurations.

module.exports = {
  settings: {
    'import/resolver': {
      typescript: {
        // a list of tsconfig.json to use
        project: ['tsconfig.json', 'packages/*/tsconfig.json']
      }
    }
  }
};

Ignoring TypeScript Errors

This feature allows the resolver to ignore TypeScript errors when resolving paths. It is useful when you want ESLint to focus on import/export issues without being blocked by TypeScript compilation errors.

module.exports = {
  settings: {
    'import/resolver': {
      typescript: {
        // ignore TypeScript errors
        alwaysTryTypes: true
      }
    }
  }
};

Other packages similar to eslint-import-resolver-typescript

eslint-import-resolver-node

This package provides a resolver for the ESLint plugin import that resolves node modules and commonjs modules. It does not have TypeScript-specific features but is suitable for projects using plain JavaScript.

eslint-import-resolver-webpack

This resolver is designed for projects using Webpack and allows ESLint to resolve module paths based on the Webpack configuration. It supports features like Webpack aliases and modules, which can be similar to TypeScript path aliases but is tailored for Webpack-specific configurations.

eslint-import-resolver-babel-module

This package integrates with Babel and allows ESLint to resolve modules using Babel's module resolver plugin. It is similar to eslint-import-resolver-typescript in that it helps resolve non-standard module paths, but it is focused on Babel rather than TypeScript.

README

eslint-import-resolver-typescript

This plugin adds TypeScript support to eslint-plugin-import (Or maybe you want to try eslint-plugin-i for faster speed)

This means you can:

• import/require files with extension .cts/.mts/.ts/.tsx/.d.cts/.d.mts/.d.ts
• Use paths defined in tsconfig.json
• Prefer resolving @types/* definitions over plain .js/.jsx
• Multiple tsconfigs support just like normal
• imports/exports fields support in package.json

TOC

• Notice
• Installation
• Configuration
• Options from enhanced-resolve
  • conditionNames
  • extensions
  • extensionAlias
  • mainFields
  • Other options
  • Default options
• Contributing
• Sponsors
• Backers
• Changelog
• License

Notice

After version 2.0.0, .d.ts will take higher priority then normal .js/.jsx files on resolving node_modules packages in favor of @types/* definitions or its own definition.

If you're facing some problems on rules import/default or import/named from eslint-plugin-import, do not post any issue here, because they are just working exactly as expected on our sides, take import-js/eslint-plugin-import#1525 as reference or post a new issue to eslint-plugin-import instead.

Installation

# npm
npm i -D eslint-plugin-import eslint-import-resolver-typescript

# pnpm
pnpm i -D eslint-plugin-import eslint-import-resolver-typescript

# yarn
yarn add -D eslint-plugin-import eslint-import-resolver-typescript

Configuration

Add the following to your .eslintrc config:

{
  "plugins": ["import"],
  "rules": {
    // turn on errors for missing imports
    "import/no-unresolved": "error"
  },
  "settings": {
    "import/parsers": {
      "@typescript-eslint/parser": [".ts", ".tsx"]
    },
    "import/resolver": {
      "typescript": {
        "alwaysTryTypes": true, // always try to resolve types under `<root>@types` directory even it doesn't contain any source code, like `@types/unist`

        // Choose from one of the "project" configs below or omit to use <root>/tsconfig.json by default

        // use <root>/path/to/folder/tsconfig.json
        "project": "path/to/folder",

        // Multiple tsconfigs (Useful for monorepos)

        // use a glob pattern
        "project": "packages/*/tsconfig.json",

        // use an array
        "project": [
          "packages/module-a/tsconfig.json",
          "packages/module-b/tsconfig.json"
        ],

        // use an array of glob patterns
        "project": [
          "packages/*/tsconfig.json",
          "other-packages/*/tsconfig.json"
        ]
      }
    }
  }
}

Options from enhanced-resolve

conditionNames

Default:

[
  "types",
  "import",

  // APF: https://angular.io/guide/angular-package-format
  "esm2020",
  "es2020",
  "es2015",

  "require",
  "node",
  "node-addons",
  "browser",
  "default"
]

extensions

Default:

[
  // `.mts`, `.cts`, `.d.mts`, `.d.cts`, `.mjs`, `.cjs` are not included because `.cjs` and `.mjs` must be used explicitly
  ".ts",
  ".tsx",
  ".d.ts",
  ".js",
  ".jsx",
  ".json",
  ".node"
]

extensionAlias

Default:

{
  ".js": [
    ".ts",
    // `.tsx` can also be compiled as `.js`
    ".tsx",
    ".d.ts",
    ".js"
  ],
  ".jsx": [".tsx", ".d.ts", ".jsx"],
  ".cjs": [".cts", ".d.cts", ".cjs"],
  ".mjs": [".mts", ".d.mts", ".mjs"]
}

mainFields

Default:

[
  "types",
  "typings",

  // APF: https://angular.io/guide/angular-package-format
  "fesm2020",
  "fesm2015",
  "esm2020",
  "es2020",

  "module",
  "jsnext:main",

  "main"
]

Other options

You can pass through other options of enhanced-resolve directly

Default options

You can reuse defaultConditionNames, defaultExtensions, defaultExtensionAlias and defaultMainFields by require/import them directly

Contributing

• Make sure your change is covered by a test import.
• Make sure that yarn test passes without a failure.
• Make sure that yarn lint passes without conflicts.
• Make sure your code changes match our type-coverage settings: yarn type-coverage.

We have GitHub Actions which will run the above commands on your PRs.

If either fails, we won't be able to merge your PR until it's fixed.

Sponsors

1stG	RxTS	UnTS

Backers

1stG	RxTS	UnTS

Changelog

Detailed changes for each release are documented in CHANGELOG.md.

License

ISC