Update the standalone test runner to compile Typescript sources at runtime by austinEng · Pull Request #378 · gpuweb/cts

austinEng · 2020-11-20T17:34:32Z

No description provided.

austinEng

Here's the overall structure, still need some tweaks. Sending it out now for early feedback.

austinEng · 2020-11-20T17:35:34Z

service-worker/index.ts

+              tsconfig['compilerOptions']['moduleResolution']);
+
+            // https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API
+            const output = ts.transpile(file, compilerOptions);


Would be good if this could use Babel as well since that's what we use for the actual build.

austinEng · 2020-11-20T17:36:04Z

standalone/index.html

      <input type="button" id="copyResultsJSON" value="Copy results as JSON">
    </p>
+    <script>
+      if ('serviceWorker' in navigator) {


Need to guard this on some define like IS_STANDALONE_DEV or something

What would that do? This file is only used for standalone dev. Should probably throw an exception if service workers aren't available.

It's also used for the standalone build that's published to gh-pages.

Maybe we could also turn this file into a template.

ah, right, got it.

austinEng · 2020-11-20T17:37:04Z

package.json

-    "typescript": "^4.0.3"
-  }
+    "typescript": "^4.0.3",
+    "val-loader": "^2.1.2",


val-loader is unused.

kainino0x · 2020-11-20T19:33:29Z

service-worker/tsconfig.json

@@ -0,0 +1,10 @@
+{


May not be relevant with babel, but this is only used in service-worker/index.ts I assume? Could we just hardcode these into that file?

This tsconfig is for the actual service-worker/index.ts file. But it imports the root tsconfig.json for runtime compilation of the other sources.

kainino0x · 2020-11-20T19:34:38Z

standalone/index.html

      <input type="button" id="copyResultsJSON" value="Copy results as JSON">
    </p>
+    <script>
+      if ('serviceWorker' in navigator) {


What would that do? This file is only used for standalone dev. Should probably throw an exception if service workers aren't available.

kainino0x · 2020-11-20T19:35:13Z

standalone/index.html

+            const script = document.createElement('script');
+            script.type = "module";
+            script.src = "../src/common/runtime/standalone.ts";
+
+            document.body.append(script);


Could this be just import('../src/common/runtime/standalone.ts')?

Yea, probably.

kainino0x · 2020-11-20T19:37:33Z

build/webpack.dev.js

@@ -0,0 +1,67 @@
+const path = require('path');


How does webpack get triggered?

This is happening with npm run dev. Which will both start and http server and watch changes to recompile if the service worker file changes (maybe a but overkill but was very nice for development).

kainino0x · 2020-11-20T19:40:01Z

build/listing-loader.js

+
+// See https://webpack.js.org/api/loaders/.
+// Module loader that replaces an import with a module that contains the generated
+// listing for a test suite. Assumes the listing is at /path/to/{suite}/listing.ts.


I was thinking for the moment we might still require a build step when new files are added. OTOH, if we have code to generate listing.ts running server-side (which I assume this is?) then should we just do all the TS compilation server-side...?

I didn't actually verify this yet, but Webpack's watcher should regenerate the listing on changes. If it doesn't we should be able to set it up to do that.

But yea you're right we could probably make all the compilation happen server side without the need for service worker. It'll probably be faster that way too.

It might be cleaner to just write our own http server for this.

I'm going to try our own http server. It avoids bundling shenanigans and is less memory and is much simpler, especially if we intend for this to be dev only.

Sounds good. I really would like to go the service worker route for WPT someday, but given we have no way to do this now with a reasonable file size, this does seem more straightforward.

I was pretty excited about this, but now seeing that the compiles take tens and sometimes 100-something milliseconds (maybe cause the browser is busy doing something else like fetching, etc.) it seems like it potentially could be rather detrimental for test runner performance and increase run times on CI a lot. Maybe the code structure could be better, because it looks like with the service worker, fetches and compiles aren't happening in parallel. If we did Promise.all of all the dynamic imports instead of awaiting each, maybe this would be less of a problem.

How do you imagine we would go the service worker route for WPT while maintaining a reasonable file size?

WPT gains a fetch deps + build step? (might as well just compile the TS here)

We use a tiny TS compiler?

If we want WPT service worker to happen in the nearish-term, maybe we should stick with service worker on standalone so most of the code is there.

another important bit here is that service worker won't work if you serve the CTS from a remote server. It's explicitly allowed for localhost, but if you try to get at it from some random IP address, service worker isn't available - unless you run with --disable-web-security

We can definitely get the fetches to happen in parallel. Though I assume by default the service worker won't actually parallelize the synchronous TS compilation?

My only idea for WPT is to use a tiny TS compiler (I haven't been able to find any such thing, even though it's theoretically possible), or get approval to drop a big dep into WPT (no idea how likely).

Good to know about the localhost thing, is that it would work on localhost or https but not http?

Yup, exactly

Server version is in #386

austinEng · 2020-12-02T22:48:53Z

Closing in favor of #386

austinEng added 2 commits November 20, 2020 09:32

standalone: compile Typescript sources at runtime

d331228

Remove Grunt tasks no longer needed for standalone

36456d4

austinEng commented Nov 20, 2020

View reviewed changes

austinEng requested review from Kangz and kainino0x and removed request for kainino0x November 20, 2020 17:38

kainino0x reviewed Nov 20, 2020

View reviewed changes

Remove unused val-loader dependency, simplify standalone.ts import

3c09ec4

austinEng linked an issue Nov 24, 2020 that may be closed by this pull request

Transpile TypeScript at runtime #314

Closed

austinEng closed this Dec 2, 2020

Conversation

austinEng commented Nov 20, 2020

Uh oh!

austinEng left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

austinEng commented Dec 2, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants