Transpile TypeScript at runtime about cts

[kainino0x]

Austin recently managed got this working with Service Workers(!). This was the original idea, but it's a bit scary especially in WPT because we'll have to install a Service Worker proxy which might interact with ALL wpt tests and not just ours.

At some point we (Austin I think) had an alternate idea to just generate another module format, like AMD, and then somehow hook into it to do the transpilation. This seems much safer.

Today I played with AMD a bit and managed to make the entire standalone runner work with pre-built AMD modules and RequireJS (#312) - it turned out to be surprisingly easy. Runtime transpilation should be easy as well, with https://babeljs.io/docs/en/babel-standalone . However, I didn't look into hooking RequireJS except to determine it doesn't appear to be super easy.

It could be reasonable to use something lighter than RequireJS, but it doesn't actually matter for our use-case. But maybe we can start with some really minimal AMD loader and just modify it. We only need to handle what Babel spits out.

cc @austinEng @egalli

[kainino0x]

It might be possible with an AMD plugin, I don't understand how those work entirely but they seem feasible.
https://github.com/mikach/requirejs-babel?

[austinEng]

Maybe also SystemJS which is apparently smaller than RequireJS - not sure if there's a significant difference in functionality. Seems like they do the same thing.

Here's the main commit of the prototype service worker idea for reference: e792aa2. I used webpack for convenience to make the actual service worker b.c. I wanted to require the tsconfig.json file, but we don't need to take the dependency if we actually go this route. Right now it's using the Typescript compiler API but we could switch it to use Babel.

Biggest pro of service worker is there's no need to hijack require or import to do an async fetch, compile and then eval the contents - or Kai suggested maybe possible to make a Blob and treat it as a file. There's also no need to ship a module loader and can stick with the builtin browser ES6 module loading.

In terms of intercepting requests, service worker is OK since if it's located at /path/to/wpt/webgpu/sw.js, it's not allowed to intercept requests that aren't rooted at /path/to/wpt/webgpu. The big con though is the registration lifecycle. While developing, I had some issues where two refreshes were needed to give an updated service worker control of the page. I think I've fixed the issue but not 100% certain. Unclear if this is actually an issue for WPT because presumably the bots run the tests with a clean cache so the service worker will always be brand new and not need to replace an old one.

[kainino0x]

OK. The service worker approach sounds better to me. Would be great to try to land it!

[austinEng]

We're going to need to ship probably @babel/standalone and all the presets and plugins we're using - probably do it like we do for glslang, where it it's from npm for local dev / standalone, and in WPT we upload it to some bucket somewhere so we don't commit a bunch of extra stuff. Thinking then it might be useful to keep webpack as a dev dependency around so we can make a single bundle for all the runtime transpiler third party deps as a single file.

[kainino0x]

We can lift our dependency on the plugins. But we will need babel. Didn't check how large it is.

[austinEng]

Oh, presumably we can't lift @babel/preset-typescript though which includes @babel/plugin-transform-typescript?

[kainino0x]

Right, forgot it wasn't in core. Agree.

[kainino0x]

This local copy of babel.min.js I downloaded the other day is 2.1M 😰

[austinEng]

and Typescript is 2.7M :-/ depends on how long it takes to fetch on test runs - does the WPT harness fetch it or does it get copied to a local file?

[kainino0x]

I believe we would have to check it into WPT.

[austinEng]

Would that be a non-starter? We could try to slim it down, but we might not get far. Just pulling in the transpile function from typescript is going to be 2.4M, minified. Maybe could be smaller, but it supports all the compiler options and src/target module formats so tree shaking isn't going to help us.

[kainino0x]

Probably not a non-starter but I'd be concerned about needing to take TypeScript or Babel upgrades at some point in the future.

I also wonder if any other projects in WPT would be interested in using TypeScript.

I searched but couldn't find a lightweight implementation that "just" parses typescript and strips the typescript features. But in theory there might be something out there.

[kainino0x]

maybe it's easy to glue @typescript-eslint/parser to something like astring? Wonder how heavy it would be.

[kainino0x]

Apparently that would take a dep on typescript as well as a bunch of other stuff. https://bundlephobia.com/result?p=@typescript-eslint/[email protected]