Feature request: import/extensions autofix

[csvan]

With Node 13.2 and up now having near-stable support for ESM modules, existing projects will need to update their imports in order to make use of it. According to the docs:

A file extension must be provided when using the import keyword. Directory indexes (e.g. './startup/index.js') must also be fully specified. This behavior matches how import behaves in browser environments, assuming a typically configured server.

(https://nodejs.org/api/esm.html#esm_mandatory_file_extensions)

Currently, while the import/extensions plugin can be configured to throw if an import doesn't have a proper ending, it does not provide a way to autofix it. Having that would be a tremendeous benefits to existing, large codebases migrating to native modules.

[ljharb]

Existing projects don’t need to do anything; there’s no particular reason anyone needs to switch to native ESM, and published packages likely shouldn’t.

That said, it seems like a reasonable autofix when it’s unambiguous, but only then.

[csvan]

@ljharb no, of course no one needs to switch to native ESM. However if they want to do so, they need to, as per the spec, use file extensions in their imports. This FR makes such migrations much easier, as well as related cases. It's not a commentary on which module system to use.

[jaydenseric]

@csvan take a look at the node/file-extension-in-import rule, it can autofix:

https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/file-extension-in-import.md

{
  "node/file-extension-in-import": ["error", "always"]
}

[csvan]

Thanks @jaydenseric, I will check it out

[cat-walk]

I also hope to has an 'autofix' function for the rule 'import/extensions'. Except for the case @csvan mentioned, there are many other cases that need the 'autofix'. For example, when using react/vue or other framework that may has different extensions.

[jimmywarting]

Existing projects don’t need to do anything; there’s no particular reason anyone needs to switch to native ESM, and published packages likely shouldn’t.

There are reasons now, many are already switching...

[ljharb]

There still are no reasons, except that a tiny number of authors (only one of whom unfortunately represents a large number of packages) have decided to be user-hostile and switch to ESM-only. That will only force people to stay on old versions or find a better package, but in the meantime it will cause a lot of pain to their users.

[DMXL]

There still are no reasons, except that a tiny number of authors (only one of whom unfortunately represents a large number of packages) have decided to be user-hostile and switch to ESM-only. That will only force people to stay on old versions or find a better package, but in the meantime it will cause a lot of pain to their users.

ignorePackages?

[wmertens]

so eslint-plugin-node has an autofix but it can't handle directory imports. It would be great if eslint-plugin-import could do this, since it's so much smarter.

ESM is slowly becoming inevitable. Node-fetch v3 and Microsoft's pnpjs are two examples of ESM-only packages with no alternatives.

[ljharb]

@wmertens i don't think 2 packages represents an indication that anything is becoming "inevitable". node-fetch has many alternatives, including an experimental one in node itself, for example.

Once resolve supports "exports" (which i'm steadily working on), we'll be able to do a proper autofix here for many of these scenarios.

[ntucker]

@csvan take a look at the node/file-extension-in-import rule, it can autofix:

https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/file-extension-in-import.md

{
  "node/file-extension-in-import": ["error", "always"]
}

This is replacing with .ts instead of .js like it's supposed to

[tjx666]

No autofix, this rule lose half of meaning

[ljharb]

@tjx666 any rule is valuable with or without autofixing; but certainly autofixing is nice to have!