Request for feedback on draft proposal

[dmchurch]

I've had a brainstorm for a TC39 proposal that partially builds off the work done on the JSON Modules specification, and I was hoping I could get some feedback from the JSON Modules champions on its viability, especially with regards to web security and browser adoption. I've written it up as a draft on the TC39 discourse:

https://es.discourse.group/t/proposal-parser-augmentation-mechanism/2008

It's a specification for an extensible syntax for defining, declaring, and requesting alternate parsing modes for any given module, much like the JSON Modules specification does. There are two crucial distinctions in behavior between the Parser Augmentation proposal and JSON Modules, however (aside from the obvious one that Parser Augmentation is extensible to other syntaxes besides JSON):

1. Parser augmentation is based around the concept of input transformation, rather than synthetic modules. Rather than performing a JSON.parse() at import time and storing a closure that creates a synthetic export, an augmentation-based JSON Module would instead translate the source text into the AST equivalent of export default JSON.parse("<the full source text>"), in which all the tokens except for the source text string constant are marked as "synthetic".
2. Parser augmentation uses ECMAScript to describe the transformations, rather than ecmaspeak abstract algorithms. However, the ECMAScript transformation descriptions are treated much the same way as abstract algorithms: they are not, under normal circumstances, observable by the runtime, and only the outputs matter. Hosts are required to make the algorithm description of any supported transformation type available by returning a string of ECMAScript code from the appropriate capability query, but they are explicitly not required to allow registration of new parse types; and, unless support for a given transformation is mandated by the spec (like the "json" transformation, if this proposal were based on parser augmentation) a host is allowed to refuse to execute a transformation based on any combination of referrer, URL, or import attributes.

Please note that this isn't a suggestion that the JSON Modules proposal be "rebased" against the currently-nonexistent Parser Augmentation module, given its current acceptance status. If anything, the JSON modules portion of the spec could be retconned in some hypothetical future without change of functionality; the equivalent "transformation description" might look something like the following:

async function json(parser) {
  parser.setTokenizerMode(Parser.TOKENIZER_STRING_CONSTANT);
  const stringConstantToken = await parser.parseInput();
  return Parser.syntheticAST`export default JSON.parse(${stringConstantToken})`;
}

This code would likely never get executed by any browser, just as the JSON.parse method will likely not actually get called in the current JSON Modules spec. However, it would provide one piece of functionality that the JSON Modules proposal currently does not: a canonical ECMAScript equivalent for any module loaded as a JSON module. Bundlers and transpilers could use this information to transform a JSON module or any other ECMAScript-equivalent module type defined in the future into a format understood by any host, even ones that don't support Parser Augmentation at all.