Allow mapping of expected extensions in import/extension rule

Context:

I have a typescript project for a node application using ESM (ecmascript modules) Because node requires that file extensions be specified for relative imports when using esm, typescript files must import relative modules with the “.js” extension. Using a typescript resolver enables linting to resolve these modules well, but when trying to enforce file extensions using the import/extensions rule, the linter expects the file extensions to be “.ts”. I would like a way to configure the rule to assert that extension rather be “.js”

Repro :

applying linting rules

npx eslint .

in the following gist https://gist.github.com/pwhissell/165232e5fdd62641efa771f000f1e651

Current output:

1:31 error Missing file extension "ts" for "./other.js" import/extensions 2:33 error Missing file extension "ts" for "./another" import/extensions

Expected:

2:33 error Missing file extension "js" for "./another" import/extensions

Example usage:

rules: { import/extensions: ["error", {"ts", "ignorePackages", "js"}] #<-- this would tell the linter that modules defined in ts files should always be imported with the .js extension }

[pwhissell]

You can use those features regardless of your transpilation target; there’s no reason you need to use native ESM for that.

I’m sure your experience at tc39 gave you lots of understanding about ecmascript ambitions. Perhaps you should read a little on nodejs, esm and commonjs modules before making such claims.

here are a couple articles, posts and issues that may be helpfull

• nodejs will not support top level await when using cjs
• mandatory file extensions
• esm is now nodejs standard

I’m still a bit confused. It sounds like the TS resolver is the problem here, not the linting rule?

It sounds like you haven’t taken a look at my gist, maybe you missed the link https://gist.github.com/pwhissell/165232e5fdd62641efa771f000f1e651

the resolver resolves the module well (wether the “.js” extension is present or not) but the “extension” linting rule enforces a .js extension

should i draft a PR?

[ljharb]

@berniegp the only things type module do are 1) make .js be ESM instead of CJS, which breaks compatibility with older nodes that assume .js is always CJS; 2) in some cases shuts off normal node resolution of extensions and index; 3) breaks tooling (like this plugin, which uses resolve) that doesn’t yet support exports or type.

If you just name your ESM files .mjs, everything works fine, and you don’t run into any of these problems.