test(wtr): enable custom elements registry tests @W-19097891#5509
test(wtr): enable custom elements registry tests @W-19097891#5509
Conversation
instead of weird fake module
There's no setup/teardown needed, it's a single test, and WTR provides per-file encapsulation
working toward just importing and executing things, but not quite there yet
two env vars for the same goal is unnecessary
I think the last one was a concurrency related timeout, which was previously addressed.
helper files shouldn't have side effects; all setup should be in the setup file
no longer necessary
all tests are run in isolation
helpful when debugging
it's just one code blob now, not multiple scripts
ensures we never accidentally use the wrong one
| // of us to use it it directly. | ||
| // '../'.repeat(depth) becomes `/__wds-outside-root__/${depth}/` | ||
| const depth = outside.length / 3; | ||
| return `/__wds-outside-root__/${depth}/${filepath}`; |
There was a problem hiding this comment.
@wjhsf does this mean that @web/dev-server will handle appending the ../ for us?
There was a problem hiding this comment.
/__wds-outside-root__/ is a magic path provided by @web/dev-server as a workaround for the fact that you can't ../ out of a web root (in our case, packages@/lwc/integration-not-karma).
When we serve pages with code like import * as LWC from 'lwc', @web/dev-server transforms that import before serving because node-style imports don't work in the browser. First it resolves the path, in this case to ../lwc/index.js. But that import wouldn't work, so it gets transformed again to /__wds-outside-root__/1/lwc/index.js. And then when the browser requests that file, the server knows where to look.
That's fine and dandy for regular imports, but sometimes we do weird hacky nonsense that needs the same transformation, but @web/dev-server doesn't do it for us. So we do it ourselves.
|
|
||
| return `(() => { | ||
| globalThis.process = { env: { NODE_ENV: "production" } }; | ||
| globalThis.LWC = globalThis.exports = {}; |
There was a problem hiding this comment.
LWC is loaded as a CommonJS module, so it must have exports defined in order to work. And then we want to save those exports as a global variable.
| } | ||
|
|
||
| const LWC = window[globalLWC]; | ||
| const lwc = window[globalLWC]; |
There was a problem hiding this comment.
nit: prefer all-caps for globals?
There was a problem hiding this comment.
In this situation, globalThis.LWC exists, but is not necessarily the same as the local variable. I intentionally used a different name to avoid shadowing.
Co-authored-by: James Tu <jmsjtu@gmail.com>
4 participants
Details
To cleanly test how LWC behaves with the custom elements registry, the tests run in iframes. Getting the right code to run in the iframes had some karma-specific logic that needed to be changed, and I tried to modernize the code (async/await) and make it a bit more clear what is going on.
Does this pull request introduce a breaking change?
Does this pull request introduce an observable change?
GUS work item