Allow imports with .js extension for package.json "type": "module" esm compatibility.

[jamie-pate]

🚀 Feature request

Reconsider #4591 which would require a webpack extension to allow developers to import modules using the '.js' file extension even though they are '.ts' files before compilation.

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

I am working on a split back-end/front-end project and trying to use "type":"module" in both package.json files but I'm currently unable to update to es modules on the client side because webpack cannot resolve typescript modules if the import ends with '.js' instead.

See https://nodejs.org/api/esm.html#mandatory-file-extensions

Since TS 2.0, it's possible to :
import { Something } from './something.js';// <- this is actually ./something.ts in the working directory.

Module identifiers allow for .js extension

Before TypeScript 2.0, a module identifier was always assumed to be extension-less; for instance, given an import as import d from "./moduleA.js", the compiler looked up the definition of "moduleA.js" in ./moduleA.js.ts or ./moduleA.js.d.ts. This made it hard to use bundling/loading tools like SystemJS that expect URI's in their module identifier.

With TypeScript 2.0, the compiler will look up definition of "moduleA.js" in ./moduleA.ts or ./moduleA.d.ts.

It's also important to be compatible with ES6 modules, which require the .js extension, as <script type="module"></script> is standard in evergreen browsers, and as for now TS doesn't provide an option to add the .js extension in transpiled files (see microsoft/TypeScript#13422).

Describe the solution you'd like

Add the resolve-typescript-plugin (or have an option to enable it) to the generated webpack config.

Describe alternatives you've considered

Currently I'm just running a split project where the server package requires '.js' extensions and the 'client' package does not. This is obviously not ideal.

Custom webpack builder can probably do this with this plugin: resolve-typescript-plugin

Nodejs can apparently be configured to experimentally customize the resolution algorithm

[alan-agius4]

By the looks of it, I am assuming that you are not using the Angular CLI to generate your server bundle. Since when using the CLI, the server bundle is also bundled using Webpack which will remove any imports. Therefore, this is quite a particular use-case which it would be better covered using a 3rd party builder such as ngx-build-plus or custom-webpack.

[jamie-pate]

Mostly I was wondering if it was time to revisit the concept, as it seems like mandatory extensions are going to be standard, and the various players in the js/ts space (non bundled at least) seem to have settled on something.

I'm dreaming of a world where we can just settle on one way to do stuff like this and stop the treadmill (or at least slow it down 🤣) maybe one day we can have legit esm modules and completely rely on http2 push etc to live in a completely bundle-free 'works the same everywhere' world.

[alan-agius4]

I think bundling will always be there and always be beneficial for a production build. As it is today, this is also the case for server applications, where bundling an application provides faster server boot times, less memory footprint and also at time slightly faster execution.

Using ESM modules directly is definitly something that we want to look into but this is for development purposes.

[jamie-pate]

Thinking of the people from the middle to the right of this graph :D no bundling for dev and moderate sized apps to reduce build complexity would be a win for that part of the audience

But also just a unified dev landscape so you don't have to change the way your project is written based on whether it's bundled, unbundled etc (the mandatory extensions thing is very high friction in that regard)

[alan-agius4]

Closing due to lack of interest from the community around this feature.

Let's re-consider this in the future if things change.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}