Support `.js` extensions.

[MicahZoltu]

import { ... } from './foo.js'

Expected Behavior:

This should compile by resolving the import to ./foo.ts.

Actual Behavior:

Errors complaining that it cannot find ./foo.js.

---

• ES2018 module loaders do not do any extension inference.
• TypeScript compiler does not append any extension to import statements in generated files.
• TypeScript will infer ./foo.ts from ./foo.js during compilation.

In order to write TypeScript that is compatible with ES2018 module loaders, you must therefore do import ... from './foo.js'. TypeScript compiler will see this import and guess that you mean foo.ts or foo.d.ts. However, ts-node does not and instead will error saying it cannot find foo.js.

While my personal opinion on this matter is that the inability for ES2018 module loaders to append a default file extension to packages that have no extension is unfortunate, it is none the less the situation we are currently in. The hope is that eventually the TypeScript compiler will be able to be given a flag that tells it to add .js when none is present, thus allowing us to write import ... from './foo' and have that generate JS like import ... from './foo.js', but that day is not yet here.

Related issues:
microsoft/TypeScript#16577
microsoft/TypeScript#28288

[blakeembrey]

This sounds largely up to TypeScript to define the working functionality, then ts-node to figure out if it'll work with node.js natively. Specifying ./foo.js definitely won't work natively since that file doesn't exist, it could be named ./foo.jsx, ./foo.tsx, ./foo.ts, etc - resolution would need to be taken on with this module. It'd be a lot quicker during compilation if you specified ./foo.ts and used the "module specifier rewrite" suggestion for tsc, and in ts-node we just discard that rewrite for things to continue working as expected.

[MicahZoltu]

The current working functionality of tsc does not match ts-node. The links I provided discuss potential future functionality, but at the moment tsc and ts-node do not behave the same, and if tsc doesn't change its behavior then ts-node will, over time, become more and more incompatible with libraries and projects that are targeting modern ES. I see you marked this as an "enhancement" rather than a "bug", this conflicts with my understanding that ts-node and tsc are supposed to behave as close to the same as possible (which, in this case, they do not)?

I was under the impression that ts-node was using ts-server under the hood, which already does this sort of path resolution. Perhaps the path resolution logic is in a higher layer that ts-node doesn't get for free?

---

What "module specifier rewrite" are you referring to? The one in microsoft/TypeScript#16577 that people are asking for but hasn't been implemented or approved for inclusion yet in tsc?

[blakeembrey]

@MicahZoltu In which way, other than having no transpiled output, does tsc not match ts-node? The difficulty on ts-node is two-fold, 1. there's transpile-only mode that does not resolution and 2. even with resolution, TypeScript doesn't rewrite module specifiers today. This means any file that's referenced would not actually exist in ts-node without using the original filename over transpiled output filename. The workaround here may be to add transforms that rewrite it back to the resolved filename, but this is quite complex and won't work in the first case I mention earlier. Overall, hopefully the solution in TypeScript is the module specifier rewrite (e.g. microsoft/TypeScript#16577 (comment)) because it makes life a bit easier, and also makes resolution a bit quicker (e.g. direct source references would be faster than checking each combination on the compilation side, where checking each file is up to 5x - .js, .jsx, .ts, .tsx, .d.ts, etc). There's also considerations for supporting extensions that TypeScript doesn't understand, e.g. import "foo.css", so this issue feels largely in the land of TypeScript and not ts-node to resolve.

[MicahZoltu]

Ah, I think I understand the problem better now. The issue isn't that ts-node is failing to compile the typescript, it is that it is failing to execute the compiled code.

script.ts

import { Foo } from 'foo.js'
new Foo()

foo.ts

export class Foo {}

If I tsc && node script.js it will run. If I try to do ts-node script.ts it will fail because it can't find foo.js.

I now better understand (correct me if this is wrong) that this is because ts-node doesn't pre-compile the whole project, it compiles files as-needed. So after it compiles script.ts (which will compile fine because TSC is loose with the extensions during resolution), it will begin executing it and upon reaching the attempt to import foo.js it will look for, and fail to find, a file named foo.js.

[blakeembrey]

Pretty much, yes. Technically, when type-checking, it has compiled the file already but then node.js takes over resolution and will fail to find the file because .js was never written to disk. It might actually be possible for the approach you describe to work if we add a mapping layer to cache the output path from input path, but it won't work with --transpile-only so I'd prefer to wait to see how TypeScript solves this first. Or add it behind a flag if you'd really like to see it work. Alternatively, doing import {} from './foo.ts' should work, but won't work in regular node.js - it's a little chicken and egg issue that's easily solved if TypeScript does some path munging for us.

[MicahZoltu]

add it behind a flag if you'd really like to see it work

Ran into this again today, I would like to throw in a vote on my own issue (which I had forgotten I created until I searched GitHub) that ts-node get something like this added (behind a flag is fine). I'm working a lot with esNext code, and at the moment I'm in a pretty bad spot because if I write a library such that it works with esnext, I can't run it with ts-node which is how I do all of my testing. If I write it so it works with ts-node, then it will fail when it comes time to run in the browser.

If there isn't interest in getting a flag added to ts-node that tells it to "infer .ts if .js is missing", then I'll probably have to switch over to running my tests by compiling to JS first, then executing them (which greatly complicates my build process unfortunately).

[blakeembrey]

I’m not sure I understand the request of inferring TS when JS is missing, or the linked commit. Both these describe how the module already works today. It doesn’t work with an explicit extension which is different.

[MicahZoltu]

foo.ts

class Foo() {}

bar.ts

import { Foo } from 'foo.js' // A
import { Foo } from 'foo' // B

A will compile and the emitted output will run natively in a browser. It will not work in ts-node.
B will compile and the emitted output will not run natively in a browser. It will work in ts-node.

The request here is to make A work in ts-node (perhaps with a flag) because there is no movement on fixing B in browser or TypeScript, and if I have to choose between ts-node support and browser support, I'll choose browser support. I don't want to have to make that choice though since I really like things working in ts-node (makes testing much cleaner/easier/better).

[blakeembrey]

I see, I was confused by the commit referenced because I thought you meant the extension missing, not the file. You should submit a PR if you want any progress on this issue.

[MicahZoltu]

I took a gander at ts-node to see how difficult a PR would be. IIUC, once a single file is transpiled, it is handed off to nodejs to execute. Nodejs will encounter a line like ... require('./foo.js') and attempt to execute that. Since ts-node has only registered itself to handle .ts files, nodejs will not callback into ts-node and instead try to load ./foo.js itself. Upon failing to find the file, it will throw an exception which will halt processing.

Does this sound correct to you? How is it that ts-node receives an opportunity to handle extensionless files, like if require('./foo') was executed?

If the above is correct, then I think the way to implement this would be to register js as an extension that ts-node handles and when such a file is compiled, ts-node will either pass through to the original js handler if the JS file exists at the specified path, or it will try to compile and return a TS file if one exists at the same path, but with a .ts extension.

Does that approach seem reasonable to you?

[blakeembrey]

If there’s no JS file on disk, node.js will not trigger the JS extension handler, so that doesn’t work. The only way to do this would be to rewrite paths before node.js executes the file to require dependencies.

[MicahZoltu]

This is getting a bit off topic, but how is it that ts-node receives a callback when nodejs encounters require('./foo')? No file exists on disk with the name ./foo, and you can't register an extension handler for '' I don't believe, and even if you could I would expect nodejs to fail during path resolution time, which is before extension handler time.