I mean, if you have a file `mod.ts`, in Deno you cannot import `mod.ts` using the following import:

  import {} from "./mod.js"

You have to write:

  import {} from "./mod.ts"

ESbuild doesn't transform source imports. Thus, by transpiling your code using ESbuild, you get an erroneous import that leads to a runtime error in browsers and Node. The case is worse for TypeScript, because it refuses to tarnspile this code.

By the way, bundling with ESbuild is possible, however when you write a library you generally want to transpile the code, not to bundle it.

I use esbuild to import .ts regularly, I'm not sure how you came to that conclusion

ESbuild correctly resolves the path, however it doesn't rewrite the import path. Thus, you end with a javascript file that tries to import a typescript file (this leads to a runtime error in the browser and Node).

We don’t put extensions on imports

    import {} from "./mod“;

and we bundle before running. Maybe that explains it.

Yes. I transpile my libraries and in order to be ESM-compatible you have to use the extension of the emitted files (in my case `.js`)

ESbuild has handled “.ts” imports for as long as I’ve used it.

TSC recently added a flag that allows “.ts” imports too.

> ESbuild has handled “.ts” imports for as long as I’ve used it.

Yes, ESbuild correctly resolves the path, however it doesn't rewrite the import path. Thus, you end with a javascript file that tries to import a typescript file (this leads to a runtime error in the browser and Node).

> TSC recently added a flag that allows “.ts” imports too.

For type-checking only. You cannot emit code when using `ts` extension.

Ah, yes, I'm assuming the code will be bundled (so all the imports will be completely rewritten anyway).

Is there a good use case where you wouldn't want to bundle TS code?

It seems to me that you either want to execute it directly (via Deno / Bun / ts-node / etc) or bundle it.

Even if you're publishing an NPM package, bundling rather than publishing individual generated .js files works well. You can either bundle your dependencies or leave them unbundled, both work just fine.

If you publish your .ts files, people can import those directly. In my experience that works much better in Visual Studio Code than importing the .js files.

Because I am publishing libraries. Generally you don't want to bundle a library, you want to transpile it. You leave the bundling phase to an application.

Transpiling instead of bundling avoids some pitfalls. Just to cite one that comes to mind: If your library has a file`a.ts` importing a file `b.ts` including the statement `export * as X from "c.js"`, you could end up with a bundled file that includes an object `X` with the exported elements of `c.js`. This prevents tree-shaking when you bundle applications that use this library.

Transpiling (or just publishing js source files if you don't use TypeScript), also allows a better debugging experience (without relying on source map).

Another point: it is currently not possible to bundle TypeScript declaration files with a regular bundle. If you bundle your sources, you end with a distribution folder with a bundled file and a myriad of lonely declaration files. This is ugly and I am not sure if TypeScript is happy with that?

However, bundling offer also some advantages compared to transpiling: the publication size is smaller, you have less compatibility issues with Deno. Maybe I will switch to bundling my libraries if it doesn't reduce optimization when bundling an application, and when bundling declarations files will be available among the bundlers.

> If you publish your .ts files, people can import those directly. In my experience that works much better in Visual Studio Code than importing the .js files.

Do you know some projects which publish their ts sources?