Hacker News Reader

Comment by antoineMoPa | Hacker News Reader

Why would anyone do this?

> 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.

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

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

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.

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.

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

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

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.

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

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.

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

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

To keep the benefits of Types w/o the burden of TS.

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.

Just add some interfaces.d.ts and import those types into jsdoc and you still have all your complexity

With modern IDE writing JSDoc comments is a fast process

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.

Reply on news.ycombinator.com