[test-runner] plugin serve() hook sees /__web-dev-server__web-socket.js request

[FredKSchott]

This seems to be a new change since upgrading from v0.7.xx to v0.9.0, where the serve() plugin hook is firing for this request. This isn't a blocker - we can ignore it in the plugin easily - but it is new behavior and a bit unexpected as a plugin author.

[LarsDenBakker]

Technically this is a virtual file created by another plugin. Depending on the ordering of the plugins, you might see files generated by other plugins pass by and that's expected.

Since this is an internal plugin, we need to see if we can make it so that the plugin is served before it passes by user plugins.

If users add other plugins, other files might pass by the serve hook though.

[FredKSchott]

Oh interesting, I didn't realize that other plugins could create files that mine would see. My plugin assumes that every request is for a project file, so I try to transform/serve everything that comes my way. Is there any rule for a "virtual file" that I could check against? I'm okay skipping anything that starts with /__web-dev-server* but it sounds like plugins could create other requests that I'd need to skip.

It would be great if every virtual file had some indicator so that I could safely ignore, like?virtual.

[LarsDenBakker]

I changed the ordering of the plugins, ensuring we always run builtin plugins first. That way user plugins never see these kinds of requests.

It's still possible for non-builtin plugins to inject any kind of code which requests/imports other files, virtual or real. It would be good to adopt some kind of convention here. Rollup uses markers like \0, but that doesn't work in a URL.

However if users make sure those plugins run before the snowpack plugin, the files would be served by those plugins before it reaches the snowpack plugin. So it would be fine in those cases.

[FredKSchott]

Thank you!

[IanVS]

I changed the ordering of the plugins, ensuring we always run builtin plugins first. That way user plugins never see these kinds of requests.

Is @web/test-runner-commands considered to be a builtin plugin? I've found that when I try to use it in one of my test files, I get errors (in vite, which is similar to snowpack) about an unresolved import of /__web-dev-server__web-socket.js. From reading this issue, it sounded like that shouldn't happen because that import should have been resolved/rewritten before it got to the vite plugin. Is that not correct?