[rcme]

> As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS.

> Of course, Svelte developers (not compiler developers) will still be provided type definition files as now, so there will be no change for Svelte developers in terms of typing.

Someone who maintains the JS debugger for VS Code added this (in response to a Svelte developers saying they couldn't use a faster compiler due to debugging difficulty):

> It's an aside from the main PR, but I'm not entirely sure what you mean here. This should not exclude the ability to use alternative TS compilers--in fact, the js debugger itself is built with esbuild. The debugger should also handle runtime transpilers (like tsx) just fine.

[yid]

ts-node [1]: am i a joke to you?

[1] https://www.npmjs.com/package/ts-node

[rcarr]

I’ve generally found tsx to be better/less hassle than ts-node

https://github.com/esbuild-kit/tsx

[paiari]

Great recommendation!

I gave tsx a test and found it has a 3x slower boot than my favorite one, tsm[0] (and this is using the native binary at "./node_modules/bin/tsx").

Unfortunately, tsm has much lower download numbers compared to tsx, so I can already see me jumping ship to it due to traction.

I usually install tsm locally with "--save-dev" and use "node -r tsm --enable-source-maps <file>.ts" to run what I want. Here on a M1 Pro 32GB the difference between both is 0.17s for tsx and 0.06s for tsm.

I urge anyone that haven't tried yet to give tsm a chance. It works great with PM2 if you create a file like "server.pm2.js" and just add at the top of it "require('tsm')" followed by "require('server.ts')".

[0] https://www.npmjs.com/package/tsm

[jjice]

Oh very cool, I'll have to look into this because ts-node can be a pain sometimes. Unfortunate name collision with the TS equivalent of JSX though.

[nailer]

ts-node is responsible for my favourite error message in all of computing.

Yes better than: 'Error: success' or 'keyboard not found: press F1 to continue'

> ts-node: Unknown file extension: ts.

Someone will reply for a technical reason about this (mentioning .mts or package.json settings or whatever) but that doesn't change the fact that a program whose only job is to run ts files should know what a ts file is. GitHub issue: https://github.com/TypeStrong/ts-node/issues/1967

tsx or @digitak/esrun both work out of the box.

[johnfn]

I'm glad you mentioned this - I had the exact same issue when using ts-node and it really blew my mind.

[mattwad]

ts-node does not play well with ESM modules out of the box. I've started experimenting with tsx but it still has some edge cases of its own. Honestly, ESM has been the bane of my existence this year as packages are slowly starting to migrate, and fixing issues lays on the developer, not any one framework.

[Tade0]

Overall the shift to ESM has been one hell of a dumpster fire.

And introducing new extensions like .mjs or .cjs is the smoldering dead raccoon responsible for half of the smell.

[maxloh]

Why don't them just use `tsc --watch`?