[scoped-custom-element-registry] Pulling in from multiple components on a page results in "Illegal constructor (custom element class..." error.

[jmurrayri]

Description

We are in an environment where scoped-custom-element-registry is being pulled in multiple times on a page (from the page itself and at least one component of the page). This was supported in 0.0.9. After upgrading to 0.0.10, we are now getting the error "Illegal constructor (custom element class..." and the page breaks.

Example

Steps to reproduce

Import scope-custom-element-registry from multiple places on a single page.

Expected behavior

Import is conditional, and essentially ignored if the component is already imported.

Actual behavior

The following error is thrown:

"Illegal constructor (custom element class must be registered with global customElements registry to be newable)"

Version

@webcomponents/[email protected]

Browsers affected

• Chrome
• Firefox
• Edge
• Safari
• IE 11

[justinfagnani]

I don't know about this one... libraries should not be including polyfills, much less this one which has never been marked as stable in any way. That will make it difficult to move to native implementations when available. You include one library that uses the polyfill and now all other libraries have to use it, even once native ships. You can also get conflicts on which version of the polyfill to use.

I'm pretty sure that we don't want to get into the business of detecting if the polyfill was installed and not installing a second time. That leads to problems where the first to load instance of the polyfill is installed, and the second isn't, even if it's newer and has bug fixes.

We might be able to make the polyfill be able to blindly install itself over another copy of the polyfill, but of course that leads to the opposite problem where the last copy of the polyfill is installed even if it's older and has bugs that were fixed in newer versions.

One direction we could go in that might help a little is to turn this polyfill into a ponyfill as much as possible, so that instead of monkey-patching the DOM, consumer of the library have to call functions exported from this library for creating registries, elements, setting innerHTML, etc. There may be some APIs that are difficult to wrap, and it wouldn't work with 3rd party libraries that call plain DOM APIs, but it possibly could work with targeted libraries like lit-html or others that can use an abstraction for DOM creation. This would be a much safer approach. cc @sorvell

[jmurrayri]

The trouble here is that the breaking change to disallow the import multiple times is packaged in the same version with a critical fix for Safari 18.4. So we need to take this upgrade asap, but really don't have time to address the other breaking change.

Would it be possible to revert the breaking change and reintroduce it in a subsequent version where we (and I would assume other consumers) would have time to react to it?

[akuzemchak]

It looks like the previous version did a check for !ShadowRoot.prototype.createElement, which got removed in #581. For developers dealing with this issue on the latest version, would that still be a valid thing to check for manually in order to determine whether or not to apply or import the polyfill? For example, could I do something to the tune of this to get around the issue?

if (!ShadowRoot.prototype.createElement) {
  // Import or apply the polyfill in some way...
}

Thanks!