> 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.
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')".
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
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.
with the difference that typescript generates the types automatically or at least tries to and in JSDoc the user needs to write the JSDoc.
Edit, btw:
Most complex types in the MR are now completly broken. It's crazy that there is a serious project out there who tries to mix jsdoc and typescript interfaces in the same project. it's like getting bad things from two worlds.
In general, your code is still valid JavaScript and can run in any browser or node environment.
Typescript probably is not going to disappear, but if it would, your code wouldn‘t have to change.
And you don’t loose your types, because the typescript compiler can interpret jsdoc as if you were using typescript directly.
10 years ago I have used Closure compiler from Google, https://github.com/google/closure-compiler/wiki/Annotating-T... , as a type checker. We had to use for production a different minimizer, not the closure compiler, but it was extremely useful to check for types and JSDoc-style annotations were very readable with minimal distraction.
Flow for JS from Facebook also supports types-as-comments, https://flow.org/en/docs/types/comments/ , but those are rather ugly as one has to intermix them with JS rather than using separated comment block on top.
