How to handle Svelte custom-element cross-dependencies and `Failed to execute 'define' on 'CustomElementRegistry`

Question

Context: We are building a library of Svelte UI components as Custom-Elements to be consumed across multiple newish and legacy applications. All components exist as packages in a monorepo, and can be maintained and delivered on their own.

Goal: to deliver small universal js packages that can be consumed ad-hoc with the least overhead by consumers.

Situation:

• a simple (atomic) custom-element such as our-button exists.
• another more complex custom-element our-modal exists which utilizes (imports) our-button

If a consumer brings in our-button-bundle.js to be used in one place and our-modal-bundle.js the duplication of our-button causes:

Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "our-button" has already been used with this registry

Not to mention, this is bringing in the code for button twice, which is bloat.

Why not use a build tool...? Ideally, we want the consumers to hardly lift a finger here. Supported apps include things like WebForms, ASP .NET, an others. As a ui team, we just want them to point as some js bundles, and go about their business. We maintain and push, they import and implement. (Hey, a team can dream at least...)

Possible Options thus far:

• An all.bundle.js No duplication of code, or naming, but Bloated. Sorry end user, you get the whole library, whether the app uses one piece, or many.
• A core.bundle.js or common small re-usable elements (similar to Vendor), and another of larger molecule like components. I can't see how this would work. With custom elements - how can pre-compiled modal compile without button? How can it be worked on in dev mode?
• A run-time script around the custom-element definitions like:

if (!window[MY_ELEMENT_NAME]) {
 // register...
} else {
 return;
}

Again, this option will send duplications of code over the wire, though only one instance of the element should be registered and used.

We could also never import any shared modules across our components, but I feel like this defeats the whole purpose of components.

Any suggestions on an architecture for this situation are welcomed.

Answer 1

The short answer is that you need to distribute the components as individual modules, such that when someone imports our-button and later imports our-modal, our-modal uses the copy of our-button that's already in the module registry.

This does mean that each (top-level) element needs its own import, and that the browser will have to download more modules than if you were distributing coarser-grained bundles, but consumers would have the option to create their own bundles.

(Shimport — disclaimer: I wrote it — allows you to use native modules even in the very few browsers that don't support them.)