support .ts in bundle-source #2415
Assignees
Labels
enhancement
New feature or request
Comments
This was referenced Aug 17, 2024
|
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:
|
|
Pure ESM has so many advantages... just being able to do For what? The beginning of the end. |
|
This in TS 5.7 might help, And this may be a better option than the WASM: |
This was referenced Nov 7, 2024
Merged
kriskowal
added a commit
that referenced
this issue
Nov 12, 2024
…ension options (for TS) (#2625) Refs: #2415 ## Description Toward support for type-erasure style TypeScript support in Endo, `.ts` files may correspond to `.mts` or `.cts` behavior in the same way that `.js` can correspond to either `.mjs` or `.cjs`, depending on `"type":` in the enveloping `package.json` (which is not necessarily the enveloping package, e.g., `src/package.json` beneath `package.json`!). We already implement this machinery for JavaScript, so this change threads additional options beside `languageForExtension` (which would map `.mts` and `.cts` to language behaviors) but also `commonjsLanguageForExtension` and `moduleLanguageForExtension`, which would get folded into the language-for-extension mapping on a package-by-package basis. ### Security Considerations None. Absent from this design is any possibility that a file would be alternately implemented as TypeScript or JavaScript. ### Scaling Considerations None. ### Documentation Considerations Includes an update to README for the new features and the undocumented features it is based upon. Includes a mention in NEWS. ### Testing Considerations TODO ### Compatibility Considerations By design error, `languageForExtension` threaded through `link` before this change, when it should have been threaded through `mapNodeModules`, since that is the machine that is aware of the `type` field in `package.json`. This change moves that internal mechanism and then adds `commonjsLanguageForExtension` and `moduleLanguageForExtension`. By common usage, this move is transparent since the option is taken at the top and simply diverted internally. However, the `languageForExtension` property could be manually threaded through `makeArchiveLite` and omitted from the options for `mapNodeModules`. I’ve elected to treat this breaking change as a bug fix since I find it unlikely anyone has taken advantage of these relatively new “lite” functions. The “lite” functions are part of the refactoring necessary to approach native XS compartment and modules. ### Upgrade Considerations None.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 Agoric/agoric-sdk#5760)
A developer who wants to write in
.tscan 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
.tsfiles directly by transparently transforming them to .js using something like https://bloomberg.github.io/ts-blank-space/ or@swc/wasm-typescriptused 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: #1656
Scaling Considerations
Test Plan
Compatibility Considerations
Upgrade Considerations
The text was updated successfully, but these errors were encountered: