Experimental forward compatible type-stripper

[fcrozatier]

Hi, I've created a type-stripper to make it possible to experiment with this proposal today. The goal is to ensure forward compatibility, so that when the proposal reaches Stage 4, a simple change in file extensions will be all that's needed.

It throws errors for unsupported syntaxes, including auto-accessors, but not for the satisfies keyword #228

[ljharb]

@fcrozatier the shape of the solution before stage 2/2.7 will likely change in many ways that guarantees you can’t have forward compatibility, in particular because TS is not a syntactic superset of JS (generics syntax, in particular).

[fcrozatier]

The transition to annotated JS (aJS) could be seamless as the proposal doesn't introduce syntax without a TS equivalent, as far as I understand. Here's how this tool could evolve to support the transition:

[x] Stage 1+: a TS → JS stripper. Assists TS users in restricting themselves to the subset of TS syntaxes with an equivalent in annotated JS
[ ] Stage 2/2.7: an aJS → JS experimental stripper. Enables early adopters to experiment with the new annotation syntax and provide feedback
[ ] Stage 4: a TS → aJS migration tool. Transpiles TS syntax to its equivalent aJS syntax

The broader picture is a clean commutative diagram:

TS ———> JS
 |       |
 |       | id
 ↓       ↓
aJS———> JS

[ljharb]

What I’m saying is that a proposal, at stage 1, is just a problem statement, not a solution shape, so there’s nothing to implement yet.

[anacierdem]

Also from what I’ve observed from the discussions here is that the proposal stopped progressing b/c of the fact that it doesn’t seem possible to come up with a forward compatible syntax. If a syntax is locked in it’d mean ts need to stop evolving or if it is left open ended, js would need to start implementing what ts has.