4 ms·

Transpiling TS is really easy task, because TS developers made huge effort to make it possible. You basically remove all types and that's about it. Probably cou

Transpiling TS is really easy task, because TS developers made huge effort to make it possible. You basically remove all types and that's about it. Probably could be done with simple character streaming algorithm. At this point, IMO, it should just be implemented within V8. Would make things much simpler for everyone.

whstl 3y ago
Totally agree. There is a TC39 proposal for that: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- MrResearcher 3y ago
  That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme-ov-file#how-does-this-proposal-relate-to-typescript https://github.com/tc39/proposal-type-annotations?tab=readme...
  - whstl 3y ago
    Hmmm good catch. But on the other hand, it would be already fantastic to have at least a subset of TypeScript...
  - WorldMaker 3y ago
    It is more compatible than not and there are workarounds for most of the things that wouldn't work, many of which you shouldn't be using in Typescript today, have known workarounds (enums), and/or you probably have lint rules already warning against using (namespaces). (There are more details elsewhere in that proposal document outside of the direct linked FAQ question.)
    - whstl 3y ago
      Great point. It is 100% possible to survive without enums and namespaces. And in fact: I bet the Typescript team itself would deprecate them (or at least add extra checks to TS to avoid them) if the TC39 proposal above passed.
      - WorldMaker 3y ago
        Yeah, if this type annotations proposal gets to higher stages I expect the associated ES target to get far more strict warnings/errors on those features. Though I'd suggest that the Typescript team also doesn't seem to be waiting on that to try to deprecate them, either. They've made it somewhat clear that the only reason enums and namespaces survive is a commitment to deep backward compatibility (both go all the way back to 1.0) and are neither features that they would add today (without waiting on TC-39 proposals for those features in JS first). As an interesting side note: up until very recent versions the Typescript code base itself was one the biggest users of both enums and namespaces. (They managed to finally do a lot of namespace removal in the very recent ESM rewrite. I haven't checked where they are at in enum removal.) It is always fascinating to me how important backward compatibility can be when you bootstrap your compiler in its own language.
chuckadams 3y ago
It's not just stripping types: enums have a runtime representation that needs to be generated.
- deleted 3y ago
  [deleted]
forty 3y ago
Why would doing work at run time that can be done at build time be a good idea? I have a CI, I'd rather have it so the build work rather than delegating that to my production servers.
- forty 3y ago
  (note that you still have to tsc everything anyway in the CI to check the types, so when you ship TS files to production your CI does the hard work, but then doesn't finish the easy part it so your prod server has to do it? Why?)
  - nsonha 3y ago
    You can also ask why every node server traverses the file system to load dependencies at runtime instead of build time. Packaging your server with bun build can be the answer to both.

whstl 3y ago

Totally agree. There is a TC39 proposal for that: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

MrResearcher 3y ago
That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme-ov-file#how-does-this-proposal-relate-to-typescript https://github.com/tc39/proposal-type-annotations?tab=readme...
- whstl 3y ago
  Hmmm good catch. But on the other hand, it would be already fantastic to have at least a subset of TypeScript...
- WorldMaker 3y ago
  It is more compatible than not and there are workarounds for most of the things that wouldn't work, many of which you shouldn't be using in Typescript today, have known workarounds (enums), and/or you probably have lint rules already warning against using (namespaces). (There are more details elsewhere in that proposal document outside of the direct linked FAQ question.)
  - whstl 3y ago
    Great point. It is 100% possible to survive without enums and namespaces. And in fact: I bet the Typescript team itself would deprecate them (or at least add extra checks to TS to avoid them) if the TC39 proposal above passed.
    - WorldMaker 3y ago
      Yeah, if this type annotations proposal gets to higher stages I expect the associated ES target to get far more strict warnings/errors on those features. Though I'd suggest that the Typescript team also doesn't seem to be waiting on that to try to deprecate them, either. They've made it somewhat clear that the only reason enums and namespaces survive is a commitment to deep backward compatibility (both go all the way back to 1.0) and are neither features that they would add today (without waiting on TC-39 proposals for those features in JS first). As an interesting side note: up until very recent versions the Typescript code base itself was one the biggest users of both enums and namespaces. (They managed to finally do a lot of namespace removal in the very recent ESM rewrite. I haven't checked where they are at in enum removal.) It is always fascinating to me how important backward compatibility can be when you bootstrap your compiler in its own language.

chuckadams 3y ago

It's not just stripping types: enums have a runtime representation that needs to be generated.

deleted 3y ago
[deleted]

forty 3y ago

Why would doing work at run time that can be done at build time be a good idea? I have a CI, I'd rather have it so the build work rather than delegating that to my production servers.

forty 3y ago
(note that you still have to tsc everything anyway in the CI to check the types, so when you ship TS files to production your CI does the hard work, but then doesn't finish the easy part it so your prod server has to do it? Why?)
- nsonha 3y ago
  You can also ask why every node server traverses the file system to load dependencies at runtime instead of build time. Packaging your server with bun build can be the answer to both.