The end of the subj section is confused:
"The translate hook returns either an eventual String value ECMAScript that will be parsed as a ModuleBody."
Previously the api returned a ModuleBody, but I think neither answer is great.
The proposed API makes performant transcoding more difficult than necessary. Source to source is fine as a lowest common denominator, but in a compiler environment, the AST or other representation may be better. As far as I can see, the Loader has no use for the source: it will only pass it back to the compiler for processing.
Also note that the next step in the processing will extract import specifiers, requiring the source to be parsed.
Based on our implementation in traceur, I suggest a small change to the API here.
Rather than translate(load) -> source, use translate(load) -> load. The Loader would set load.source (from fetch as now) on input and that's it. The Loader never needs to examine the .source.
In the bigger picture what I am suggesting is to complete the almost-great interface between the Loader and loader-hooks, allowing the Loader to be purely a dependency analysis engine entirely ignorant of all things compiler.
The load object becomes a vessel for the loader-hooks, with properties given by the Loader at each stage of the pipeline, and metadata on the load object set by the loader-hooks. (We call ours load.metadata).
Whenever the Loader needs a compiler-like result, it uses loader-hooks. This is almost true in the current design. A few more hooks may be needed. In particular we added getModuleSpecifiers(load) -> [names], so the parsing for dependencies is delegated to the hooks.
Returning to the subject of this bug: with translate(load) -> load, our loader hooks can call out to other-language translations and store the result AST or it can just parse the incoming ES6 and store the result AST. We don't need to create source code. When the subsequent cal to getModuleSpecifiers() arrives, we can answer from the AST.
concerns old module spec.