4 ms·

I would love to use Deno, however it is not totally compatible with the TypeScript ecosystem: it is not possible to import a TypeScript file using the `js` exte

I would love to use Deno, however it is not totally compatible with the TypeScript ecosystem: it is not possible to import a TypeScript file using the `js` extension. This is a dealbreaker for me because by adopting the `ts` extension you make your code deno-specific; You can no longer use TSC, ESbuild and the like.

wrs 3y ago
Not sure what you mean? Our whole codebase is .ts files, and we use tsc and esbuild without apparent difficulty.
- conaclos 3y ago
  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.
  - pipe01 3y ago
    I use esbuild to import .ts regularly, I'm not sure how you came to that conclusion
    - conaclos 3y ago
      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).
  - iainmerrick 3y ago
    ESbuild has handled “.ts” imports for as long as I’ve used it. TSC recently added a flag that allows “.ts” imports too.
    - conaclos 3y ago
      > 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.
      - iainmerrick 3y ago
        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.
        conaclos 3y ago
        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?
  - wrs 3y ago
    We don’t put extensions on imports import {} from "./mod“; and we bundle before running. Maybe that explains it.
    - conaclos 3y ago
      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`)
bartlomieju 3y ago
Bartek from the Deno team here. We are working on making this possible with a flag in the upcoming release.
- conaclos 3y ago
  Great to know!

wrs 3y ago

Not sure what you mean? Our whole codebase is .ts files, and we use tsc and esbuild without apparent difficulty.

conaclos 3y ago
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.
- pipe01 3y ago
  I use esbuild to import .ts regularly, I'm not sure how you came to that conclusion
  - conaclos 3y ago
    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).
- iainmerrick 3y ago
  ESbuild has handled “.ts” imports for as long as I’ve used it. TSC recently added a flag that allows “.ts” imports too.
  - conaclos 3y ago
    > 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.
    - iainmerrick 3y ago
      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.
      - conaclos 3y ago
        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?
- wrs 3y ago
  We don’t put extensions on imports import {} from "./mod“; and we bundle before running. Maybe that explains it.
  - conaclos 3y ago
    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`)

bartlomieju 3y ago

Bartek from the Deno team here. We are working on making this possible with a flag in the upcoming release.

conaclos 3y ago
Great to know!