extensions: use the extensionAlias option of import-resolver-typescript

[phryneas]

TypeScript with moduleResolution: "node16" requires imports like import { foo } from './tsFile.js' while on the disk, there is actually a ./tsFile.ts.
The idea here is that a module import needs a file extension and that TypeScript will not change the import statement during transpilation.

Currently, this does not work with the import/extensions rule if the eslint-import-resolver-typescript is set up - the resolver will return the original file name with the .ts extension, and the eslint rule will error since "js" !== "ts".

This PR modifies the import/extensions rule to take the extensionAlias setting into account if the typescript resolver is configured.

Related issues: #2729 and #2776

[ljharb]

is it that we depend on an older major of that plugin? or that we depend on an older minor or patch?

Probably a better option would be extracting the code into its own package, that both we and eslint-import-resolver-typescript use. @JounQin, thoughts?

[phryneas]

eslint-plugin-import doesn't have any dependency on eslint-import-resolver-typescript yet, but a devDependency on 1.0.0 || 1.1.0 - the current version is 3.5.5.
I didn't want to add a new dependency here just for that one config object, but I'm happy with whatever solution we end up with here :)

[ljharb]

ah, true enough. adding a dependency is fine, but perhaps the resolver's not ideal to add. hopefully an extracted package is viable.

[phryneas]

If that doesn't work, we could go for an peerDependency with peerDependenciesMeta optional: true.
If the package is there, use it, if it isn't we should avoid the relevant codeblock anyways.

[ljharb]

I don't want to rely on optional peers; any npm client older than that feature would treat it as required.

[phryneas]

Good point. Then let's see what @JounQin has to say :)

[JounQin]

Should it be a setting of import plugin to for using without TypeScript resolver? For example, could webpack resolver resolves same path?

[phryneas]

I think that's already the settings['import/resolver'].typescript setting?
If that's set, the import plugin will use the TS resolver, otherwise not.

[JounQin]

https://webpack.js.org/configuration/resolve/#resolveextensionalias

I mean the webpack resolver could also resolve different extensions if it's working correctly? Then only relying on the typescript resolver's setting seems incorrect to me.

[phryneas]

Maybe? I don't know what that one does, or if anyone ever had this problem with it.
The problem at hand is that this is something TypeScript expects with the node16 target, for at least the last 5 releases of TypeScript, and it is not supported by the imports/extensions rule. There doesn't seem any way of asking the resolver "is this a valid replacement file extension for this other extension", since the resolver is pretty much hidden from the rule, so I don't know a way of implementing this better.

[phryneas]

Little heads up: It's already late here, and tomorrow is public holiday, so I'll probably add the requested changes on Wednesday.

[phryneas]

Changes are in from my side :)

[ljharb]

I've rebased this; if all tests pass, then the only open question seems to be whether we can extract this logic into a package that is shared by both this plugin and the typescript resolver (cc @JounQin)

[JounQin]

I've rebased this; if all tests pass, then the only open question seems to be whether we can extract this logic into a package that is shared by both this plugin and the typescript resolver (cc @JounQin)

I'm fine to share a package but it seems the version strategy is very different between eslint-plugin-import vs eslint-import-resolver-typescript. (I don't want to support old Node versions.)

[ljharb]

You wouldn’t have to, if the extracted package does, it’d work for both.