Adding support for ESM references without a .js extension

[staplespeter]

What is the problem this feature will solve?

When running JS files output from tsc without explicit .js extensions on implicit .ts module imports, Node.js produces an error.

File X.ts:
import A from './Y';

File Y.ts:
export default const A = 10;

tsc output is to X.js and Y.js with content being identical. node X.js produces the following:
Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'Y' imported from X.js

File X.ts must contain:
import A from './Y.js';
for this import to work.

It seems there has been much discussion on this for many years, with the TypeScript team refusing to add support for File X.ts:
import A from './Y';
transpiling to File X.js:
import A from './Y.js';

See

• TypeScript cannot emit valid ES modules due to file extension issue microsoft/TypeScript#42151
• Provide a way to add the '.js' file extension to the end of module specifiers microsoft/TypeScript#16577
• bug(esm): TypeScript is not an ECMAScript superset post-ES2015 microsoft/TypeScript#50501

In places the TypeScript dev team have insisted that Node.js should be resolving the ESM dependencies correctly. Frankly either tsc or Node.js can resolve this issue. Doing so would really help A LOT of people. It would be good to see some collaboration between TypeScript and Node.js teams to make this ESM support work cleanly.

What is the feature you are proposing to solve the problem?

Add module resolution for ESM imports without an explicit .js extension when imports are within the package.

What alternatives have you considered?

Crap workarounds:

• Using .js extension in all imports
• Renaming output files post-transpilation

A seamless solution for the toolchain is what is required. Current solutions are improper, or are hacks, or leave the burden on the dev to effectively manually add the .js extensions. These are programs, they are meant to do the grunt work for devs.

[bnoordhuis]

Node already supports what you're asking, if I understand you correctly:

https://nodejs.org/docs/latest-v18.x/api/esm.html#import-specifiers - bare specifiers

[climba03003]

Node already supports what you're asking,

The ask above is about Relative specifiers which requires file extension.
Even with Bare specifiers, developer is required to specify all the possible files in exports if they would like their user to access all those without file extension. And it is not possible within the package itself.

[bnoordhuis]

Okay, cc @nodejs/modules then. I have a feeling this has already been discussed to death though.

[GeoffreyBooth]

This is a duplicate of so many that I'm not going to bother looking it up. Newer versions of TypeScript have solved this issue.

[staplespeter]

@GeoffreyBooth I'm sure this is a duplicate. I raised this here as i encountered a runtime error because I was never instructed (EVER) to add .js extensions to my ESM TS import statements. After researching the issue many people are still pissed at this TS issue. I thought perhaps a solution between Node and TS devs should have been agreed.

Newer versions of TS have not solved this issue - at least in mine and many others views. I can still transpile TS files with ESM imports with no extension and they will still fail at runtime. The solution you mention is simply to instruct devs to ensure that the imports have .js extensions.

I'm not really sure why Node couldn't resolve ESM imports without an extension

• Is it ESM or CJS?
• It's ESM, look for file with .js extension
• Not there, look for file with /index.js appended
• Not there, iterate through others cases in some kind of priority order until resolved
• Not resloved, error

I believe TS should output the correct extension as they are targeting a known platform, but TS devs have chosen that devs must use .js extensions during coding. These files don't exist. Using .ts in imports results in a build error. It's very backwards. And after 5 years of this issue only in the last month has instruction been added to the TS docs to state that .js extensions must be used. It's frankly pathetic.

So in the spirit of cooperative solutions I thought maybe Node could/would do something to help devs.

But sadly it seems both parties seem to not really care about the development experience of using their tools. I appreciate that this has been discussed before (i've searched and read previous TS issues on this but not Node, apologies), and i'm not pointing the finger at anyone here, I'm just frustrated that the customers requirements are not put first.

In any case, as has been recommended, i'm going to use Deno in the future.

[JakobJingleheimer]

@staplespeter I understand your frustration at the pain the TS team have inflicted upon you. It is entirely possible in node to work around TS's design flaw with a set-and-forget custom loader (we have even written a simple one for you: https://github.com/nodejs/loaders-test/tree/main/typescript-loader).

[climba03003]

The example doesn't seem to provide a method to ignore the extension.
So, if one of the loader need to be provide.

1. Need to search for the actual file.
2. Need to transform and add the .js / .mjs extension inside the code. (Maybe it doesn't need to.)

To me, it is asking the user to re-invent the logic (CJS Loader) inside node to workaround the problem.

[JakobJingleheimer]

To me, it is asking the user to re-invent the logic (CJS Loader) inside node to workaround the problem.

We have provided a feature that hugely reduces the level of effort needed from you to work around TypeScript's design flaw. You can expand on the loader I linked above to do so (and if you do a small bit of digging, you'll find an earlier implementation that did include the specific mismatched file extension workaround). I use that expanded version myself in my day-job.

ts-node (and possibly others) also provide a loader that fully handles this and much more than the bare-bones example provided above.