Comments (15)
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.
from cts.
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?
from cts.
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.
from cts.
OK. The service worker approach sounds better to me. Would be great to try to land it!
from cts.
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.
from cts.
We can lift our dependency on the plugins. But we will need babel. Didn't check how large it is.
from cts.
Oh, presumably we can't lift @babel/preset-typescript though which includes @babel/plugin-transform-typescript?
from cts.
Right, forgot it wasn't in core. Agree.
from cts.
This local copy of babel.min.js I downloaded the other day is 2.1M 😰
from cts.
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?
from cts.
I believe we would have to check it into WPT.
from cts.
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.
from cts.
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.
from cts.
maybe it's easy to glue @typescript-eslint/parser
to something like astring
? Wonder how heavy it would be.
from cts.
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]
from cts.
Related Issues (20)
- Rejection on createComputePipelineAsnyc causes timout in tests HOT 5
- Add tests against the extension `dual_source_blending`
- Add test for `@interpolate(flat, either)`
- wgsl: Add execution test for @interpolate(flat,first), and validation tests for `either` and `first` HOT 2
- Show a message when the tests can't run at all (like WebGPU doesn't exist or requestAdapter fails)
- `npm run wpt` generates `*.worker.js` tests that accidentally get run by `wptrunner` HOT 3
- wgsl: matrix_scalar_compund tests fail because compoundAssignmentBuilder assumes LHS and RHS are the same type HOT 2
- wgsl: compound assignment for &= and |= generating invalid WGSL when types are bool or bool vector
- skipIfTextureFormatNotUsableAsStorageTexture does not handle bgra8unorm well
- Texture format capability info does not take device into account HOT 3
- Consolidate texture format lists for tests
- bitwise_shift tests appear to be non-conformant, fails on Chrome and Safari Technology Preview HOT 4
- Report `PRECONDITION_FAILED`-ish outcomes for unavailable optional features
- `SKIP` test outcomes in standalone are significantly different from WPT's `SKIP`
- Rejection on createComputePipelineAsync causes ERROR on WPT test harness HOT 1
- Create*PipelineAsync on lost device HOT 1
- Refactor WGSL textureLoad execution tests to test more texels
- Test that bias in textureSampleBias is clamped to [-16.0, 15.99]
- Running CTS on React Native HOT 4
- Change compat shader module errors to pipeline errors
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cts.