TS to JSDoc Conversion
github.com
TS to JSDoc Conversion
1–10 of 163 posts
Re: TS to JSDoc Conversion
#2Why would anyone do this?
Re: TS to JSDoc Conversion
#3Why 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.
Re: TS to JSDoc Conversion
#4Twitter thread about it
https://twitter.com/puruvjdev/status/1655813548495486977
Re: TS to JSDoc Conversion
#5Why 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…
ts-node [1]: am i a joke to you?
Re: TS to JSDoc Conversion
#6Why would anyone do this?
To keep the benefits of Types w/o the burden of TS.
Re: TS to JSDoc Conversion
#7Earlier quoted context omitted.
> 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…
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.
Re: TS to JSDoc Conversion
#8Earlier quoted context omitted.
> 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…
ts-node [1]: am i a joke to you? [1] https://www.npmjs.com/package/ts-node
I’ve generally found tsx to be better/less hassle than ts-node
Re: TS to JSDoc Conversion
#9Why would anyone do this?
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.
Re: TS to JSDoc Conversion
#10Used to be really active in the svelte community and developed my own framework that got broad use. Getting Svelte and TS working together was a constant battle. This is a good decision.