doc: add strip-types proposal

[marco-ippolito]

Follow-up proposal for #208
Wording and bikeshedding welcome 😸

[legendecas]

Thanks! Dropped some nit picking comments. Going to take another look soon.

[joyeecheung]

Cross-posting from the slack channel, since folks seem to think this is an interesting idea..

Speaking on detection, can we do detection on TypeScript transform too? i.e. strip types and try to run it first. If there are syntaxes requiring transform, do the transform - but the transform is not part of LTS?

So instead of only having a stable subset, we include a stable subset + a never stable subset (which the TypeScript team wants, AFAICT)

[GeoffreyBooth]

I guess the question is what’s the future of these transforms. TypeScript hasn’t added new transforms in quite a while, and they seem to be phasing them out; they discourage enums nowadays per what @JakobJingleheimer found, and other transforms like private class fields and legacy decorators have been superseded by standardized syntax.

In other words, the only people needing transforms are users who’ve written older TypeScript; it seems like the transform-requiring syntax is discouraged nowadays. I’d like to hear something about this from the TypeScript team themselves, though; if they can attest that a) current transforms won’t change, and b) they aren’t adding new transforms, then sure, we might as well support transforms as there isn’t potential for breaking changes.

On the other hand, if transforms are a legacy thing, we could be more forward-looking and just never support them from the start and hasten their demise. Users who want transforms can keep running TypeScript however they are now, and we focus on the future users who will be writing a TypeScript that aligns with type stripping and the Type Annotations proposal.

[GeoffreyBooth]

The latter half of this document is just a copy of the docs from the PR, but those docs are likely to continue to change. Rather than having two documents to keep in sync, can we focus this one on the high level and just link to the PR for implementation details?

I think a good thing for this document to cover would be the pros and cons of this approach as compared with others, as that’s something that we wouldn’t discuss in the API docs.

[mcollina]

Based on yesterday's call, I think you need to add a few sections:

1. the importance of .d.ts as "headers" files underpins types long term stability
2. running .ts inside node_modules
3. grow-up path / ejecting into compiling javascript
4. monorepos

I think clarity around these points should meet @DanielRosenwasser's concerns.

---

My take is that stripping types is for end-user apps and small scripts. We should not be running .ts inside node_modules as it would fracture the ecosystem and create a "blessed" version of .ts that we support once pure ts modules are in the registry.

[marco-ippolito]

updated

[mcollina]

lgtm