I've had a brainstorm for a proposal that I think may very much be of interest to the Type Annotations champions, and if it's not too much trouble, I'd like to get some feedback on whether it would be as good a fit for the purpose as I think it will be. I wrote a draft of it on the TC39 Discourse, here:
This defines (or will define, when complete) a standards-conforming way to describe alternate parser implementations that can be used by ECMA262-compliant engines. In short, it would allow browsers to parse and execute TypeScript, Flow, or any other semantically-compatible syntax augmentation of ECMAScript, at the cost of a single declaration at the top of the file, an import attribute, or an out-of-band mechanism like an import map or an HTTP header.
Note, however, that despite appearances (and my pitch above), this is not a proposal for runtime syntax parsing by ECMAScript code - although that's one possible implementation it could take. This is (will be) a mechanism to allow engines to declare, in a standards-conforming way, what types of source transformations they support, and to allow ECMAScript-compliant code to specify which transformation(s) to use on any given source text. For example, this would provide a way for Deno to advertise its support for unprocessed TypeScript modules, along with a way for the source to declare what version of TypeScript is being used. It goes without saying that this would also function as a standards-compliant way to pass information to a bundler or transpiler, during a build process.
If this proposal were to pass, it wouldn't be necessary to figure out what subset of Flow or TypeScript syntax could be supported by the native ECMA262 parser; all that would be required is to define the validation/reference implementation using pure ECMAScript (in other words, take the parsing code from the existing transpiler and massage the generated AST into the format the Parser Augmentation framework expects, likely something along the lines of the Babel/Babylon AST), and then convince the browsers to support runtime parser augmentation, either globally or by a whitelist of known-safe implementations. So, you know, everything you'll need to do for this proposal anyway, minus the need to actually get the proposal through the TC39 process.
At a future date, if and when browser support is achieved, this Type Annotations proposal could be advanced to TC39 again, only this time it wouldn't be a request to add lots of new syntax to the language - it would just be a request to standardize the syntax identifier of a given parser definition, and it would have actual real-world usage data behind it.
I've had a brainstorm for a proposal that I think may very much be of interest to the Type Annotations champions, and if it's not too much trouble, I'd like to get some feedback on whether it would be as good a fit for the purpose as I think it will be. I wrote a draft of it on the TC39 Discourse, here:
https://es.discourse.group/t/proposal-parser-augmentation-mechanism/2008
This defines (or will define, when complete) a standards-conforming way to describe alternate parser implementations that can be used by ECMA262-compliant engines. In short, it would allow browsers to parse and execute TypeScript, Flow, or any other semantically-compatible syntax augmentation of ECMAScript, at the cost of a single declaration at the top of the file, an import attribute, or an out-of-band mechanism like an import map or an HTTP header.
Note, however, that despite appearances (and my pitch above), this is not a proposal for runtime syntax parsing by ECMAScript code - although that's one possible implementation it could take. This is (will be) a mechanism to allow engines to declare, in a standards-conforming way, what types of source transformations they support, and to allow ECMAScript-compliant code to specify which transformation(s) to use on any given source text. For example, this would provide a way for Deno to advertise its support for unprocessed TypeScript modules, along with a way for the source to declare what version of TypeScript is being used. It goes without saying that this would also function as a standards-compliant way to pass information to a bundler or transpiler, during a build process.
If this proposal were to pass, it wouldn't be necessary to figure out what subset of Flow or TypeScript syntax could be supported by the native ECMA262 parser; all that would be required is to define the validation/reference implementation using pure ECMAScript (in other words, take the parsing code from the existing transpiler and massage the generated AST into the format the Parser Augmentation framework expects, likely something along the lines of the Babel/Babylon AST), and then convince the browsers to support runtime parser augmentation, either globally or by a whitelist of known-safe implementations. So, you know, everything you'll need to do for this proposal anyway, minus the need to actually get the proposal through the TC39 process.
At a future date, if and when browser support is achieved, this Type Annotations proposal could be advanced to TC39 again, only this time it wouldn't be a request to add lots of new syntax to the language - it would just be a request to standardize the syntax identifier of a given parser definition, and it would have actual real-world usage data behind it.