support .ts in bundle-source

[turadg]

What is the Problem Being Solved?

TypeScript is very popular and the JsDoc syntax for it has many limitations compared to .ts. (Some described in https://github.com/Agoric/agoric-sdk/issues/5760)

A developer who wants to write in .ts can transpile before bundling with Endo, but that increases work, room for error, and the transformation chain to audit.

Description of the Design

bundle-source would bundle .ts files directly by transparently transforming them to .js using something like @swc/wasm-typescript used in Node's new .ts support.

Security Considerations

Transforming code can make it harder to audit the bundled code. But conversely, type annotations can mislead in an audit.

Given the complexities of audits and the trade-offs with runtime constraints, solving auditing will require purpose-built tooling: https://github.com/endojs/endo/issues/1656

Scaling Considerations

Test Plan

Compatibility Considerations

Upgrade Considerations

[mhofman]

Striping TS types and purely replacing with whitespace may cause semantic JS difference, and some cases need special handling. Any mechanism that support TS in bundle source need to correctly handle these cases and not change the runtime semantics.

Some pointers:

• Effects of types on ASI
• TS syntax can also be valid JS syntax, in particular the 3rd comment showing that experimental type erasure in Node.js results in different runtime semantics.

[kungfooman]

Pure ESM has so many advantages... just being able to do <script type="module" src="..."></script> with an import map... TS destroys nice ESM and also makes code unreadable. Simple one liner JS functions that are easy to document with JSDoc become type monsters where you can't even differ between real code and type sugar any longer without starring at ASCII soup for 5 minutes.

For what? The beginning of the end.