The ESLint plugin eslint-plugin-path-import-extension
allows automation of managing extensions of path-like imports (and exports) in TypeScript code.
The path-like import means that the import/export target (string) starts either with .
or /
.
If such import/export is detected, and it doesn't have an extension as configured for this plugin, this plugin will attempt to fix the situation by appending the extension.
It also understands targets to directories and will fix them to {directory}/index.{extension}
.
The most typical usecase for this plugin is when one is creating a library with TypeScript, that library is supposed to run in both CommonJS and ESM runtime environments.
At the same time, it is desireable NOT to use any extensions used in imports/exports within the TS code, in order to be able to run and test it without transpiling via ts-node
or other tools.
The problem that is solved by this plugin arises when often in such cases, the transpiled CommonJS and ESM codebases are placed each in its own directory as .js
files, and package.json
will have its type
set to module
.
The relative imports/exports within the ESM variant of .js
files will then become broken if included from .mjs
file (but will work if included from .js
file!).
This ESLint plugin is thus applied to the ESM variant of .js
files to transform all of the relative, extensionless imports/exports, to have the correct extension in the string literals.
One might think this is the job for TS compiler, but TS team has been adamant on their stance that TS compiler will not interfere in any way into imports/exports of the code being transpiled. Thus, this ESLint plugin will fill in the niché of needing to append extensions to imports/exports within ESM-variant JavaScript files. The plugin will, however, also work for TS code without any extra configuration.
Assuming that ESLint has already been installed
yarn add --dev eslint@latest
, install this plugin:
yarn add --dev eslint-plugin-path-import-extension
In the plugins
section of the ESLint configuration, specify the newly installed plugin:
{
"plugins": [
"path-import-extension"
]
}
Then, extend the recommended set (which configures both rules of this plugin to be treated as error
):
{
"extends": [
"plugin:path-import-extension/recommended"
]
}
Alternatively, it is possible to configure each rule individually:
{
"rules": {
"path-import-extension/require-path-export-extension": "error", // Recommended
"path-import-extension/require-path-import-extension": "error" // Recommented
}
}
Both rules exposed by this plugin take optional individual options. These options adher to single schema, which is a JSON object with the following properties:
extension
of typestring
: the extension to check for the targets of imports/exports. By default, the extension is deduced based on the extension of the source code file being processed by ESLint:.js
and.ts
files will use.js
,.mjs
and.mts
files will use.mjs
, and.cts
and.cjs
files will use.cjs
as extension to check and fix relative imports/exports.checkAlsoType
of typeboolean
: Whether to trigger the rules on targets of import/export statements which have one or moretype
specifier in them. Default isfalse
.knownExtensions
of typeArray<string>
: The extensions which will cause to be replaced (as opposed to appending) when doing auto-fix. The default is[".js", ".ts", ".mjs", ".mts", ".cjs", ".cts"]
.ignoreExtensions
of typeArray<string>
: The extensions which will cause the rule to never to trigger. The default is[".json"]
.
For more information, see JSON schema specification and TS type in source code.
All of the rules currently are fixable, and can be fixed automatically by running ESLint CLI with --fix
flag.
recommended | fixable | rule | description |
---|---|---|---|
✅ | 🔧 | require-path-export-extension | Checks and fixes the target string literals in export statements. |
✅ | 🔧 | require-path-import-extension | Checks and fixes the target string literals in import statements. |