Description

Please consider altering the polyfill to keep JSDOM's global customElements registry intact. This particular instance also includes some _internal bookkeeping the headless browser uses. Swapping it out completely breaks JSDOM down.

However by swapping it out with a Proxy-ed object that delegates to the polyfill's instance where it can, and allows fallthrough to the original instance seems to also add support to JSDOM.

Motivation

So why consider a "not a real browser" as some would put it? Currently, a large percentage of applications written with traditional frameworks (React or Vue) use Jest including JSDOM (v16+). Currently, web components are often sold to management as a future-proofing investment. Now if we take an organization adopting, say Lion Web Components, suddenly all their Jest user teams' tests start breaking after @open-wc/scoped-elements has updated to use this polyfill.

Note

As far as I managed to test it, the following change to the polyfill would solve the problem for JSDOM. I'm happy to send a PR if needed:

	// Install global registry
	const globalRegistry = new CustomElementRegistry();
	Object.defineProperty(window, 'customElements', {
		value: new Proxy(window.customElements, {
			get: (original, prop) => prop in globalRegistry ?
				globalRegistry[prop] :
				original[prop],
		}),
		configurable: true,
		writable: true,
	});