[Feature Request]: Support extensionAlias field

[patricklafrance]

What problem does this feature solve?

As mentionned in the following discussion and issue, to use Wepack (now rspack) with an ESM + TypeScript setup, the bundlers should support file extensions aliases to enable the following syntax:

// Importing from button.tsx but using the ".js" file extension to satisfy TypeScript.

import type { ButtonProps } from "./button.js"

As ESM is getting quite popular it would be great to have support for extensionAlias sooner than later 🙏🏻

TypeScript 5.0 comes with a "bundler mode" module resolution which should fix the issue but it would still be useful for organization which cannot move to TS 5.0.

Thank you

What does the proposed API of configuration look like?

Same as Webpack https://webpack.js.org/configuration/resolve/#resolveextensionalias

[jraoult]

@patricklafrance I just found this issue while trying to migrate from Webpack. Has it been really implemented and released? My configuration gets rejected with the following:

 configuration.resolve has an unknown property 'extensionAlias'

[patricklafrance]

@jraoult it has not been implementend. I closed the issue because it’s not necessary anymore with TS 5 offering the allowImportingTsExtensions configuration field.

[jraoult]

@patricklafrance thx for your reply. In my case, allowImportingTsExtensions doesn't provide the same benefits as extensionAlias. I'm sharing modules between Node and the browser. It's essential to be able to write import {...} from "./myModule.js" so it can be resolved once transpiled for the Node side (cf. https://www.typescriptlang.org/docs/handbook/esm-node.html). Neither import {...} from "./myModule.ts" nor import {...} from "./myModule" would work when using ESM resolution. So my solution was always to write the full import path with the .js extension and then get Webpack to try the .ts and .tsx when the .js doesn't resolve to an existing file.

Would you reconsider the decision not to implement it?

[patricklafrance]

Hey @jraoult

I initally created an issue because I thought it was required to support ESM+TS+Webpack but I am not a maintainer nor a contributor of rspack, therefore I have no say in that :)

Since this one is closed and your use case is different, I would recommend creating a new issue.

[jraoult]

@patricklafrance, my bad. Somehow I assumed you were one of the maintainers 😀. I'll create a new request then.