[mark_and_sweep]

Which other tooling allows you to import a `.ts` file from a `.js` import? Not knowing much about the issue, this seems like a rather strange decision to me: If I'm importing a `.js` file, and it does not exist, I'd prefer an error message rather than the sort of magic that you're suggesting: "Oh, but I found a `.ts` file with the same name, so let me just go ahead, transpile the file to JavaScript and let you import the result!" That's rather unexpected IMHO.

[hermanradtke]

This is literally how esm support in node works today unless you turn on an experimental feature flag.

https://www.typescriptlang.org/docs/handbook/esm-node.html

[conaclos]

Literally most of other tools: TSC, esbuild, bun, swc, babeljs, ... It is even the recommended way in TSC, esbuild and others to import a .ts file in order to emit esm-valid code. I understand the point of Deno. However, it is just too hard to adopt a tool that cannot be used in tandem with others.

I do not know who downvoted my comment: it is not a healthy behavior.

[mark_and_sweep]

I'm not sure you understand the point of Deno if you say that the Node ecosystem does something strange so Deno should do it, too... Magic file resolution was one of the regrets explicitly mentioned in Ryan's first talk introducing Deno.

[conaclos]

I did not say that. I think it is a good thing to do thing properly. File resolution is pretty complex (too complex) in Node/TSC. I would like others tools to support native .ts imports and translate automatically to .js on code emitting. However, it is not going to happen in the short and medium terms.

Using a fallback to .ts files when importing .js files is a minor and straightforward addition to file resolution. And this is a big gain in terms of interoperability with others tools.