Why js instead of ts?

[tonyxiao]

Would love to hear your thoughts on writing this project in js (with types as comments) rather than ts. Is it to simplify the publishing pipeline or is there something else?

[jaydenseric]

Sorry for the late reply.

One day I will write a detailed article to link people too whenever this topic comes up. Over the years I've made lots of detailed comments in various repos explaining why (e.g. jaydenseric/graphql-upload#282 (comment)), but it's not easy to dig them all up as a reference.

Of the many advantages, these ones stand out:

1. No build step. Being able to directly edit and format the published modules is a fantastic simplification.
2. The types are shipped inline within the published module. In Deno for example, when you import the module via a URL type safety just works without having to tell Deno to go get definitions over the network from a different URL.
3. When users in their editor CMD+click on exported things of this package in their code, it takes them directly to the real code they are using instead of off to a seperate TS definitions file that doesn't contain the actual code. This is a great DX improvement.
4. Significantly less bloated node_modules because you are not doubling the amount of files by having a companion .d.mts file for every .mjs file.

[tonyxiao]

3. can be solved by publishing the source, but that worsens 4) because you'd be publishing 3x, the js code, the d.ts code AND the ts code. That's what I'm doing now though.

if only all js runtime support ts by default for future...

[tonyxiao]

Great reasons though, thanks for writing it up!