Eslint-plugin-import: 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.