Labs Feedback: @lit-labs/scoped-registry-mixin

[kevinpschaaf]

The @lit-labs/scoped-registry-mixin package provides a mixin for LitElement that allows a component to choose the custom element tag name for child components it renders in its shadow root, to avoid tag name collisions in the global registry. The implementation is aligned to the Scoped CustomElementRegistry spec proposal; however since that spec is not yet shipped in browsers, it must be used with a scoped CustomElementRegistry polyfill.

We want to collect your feedback on the direction of the @lit-labs/scoped-registry-mixin package as we iterate on it according to our Lit Labs process and move the package towards possible graduation or retirement.

• Status: Prototyping
• Major known issues:
  • [labs/scoped-registry-mixin] Make compatible with subclassing #1766
  • [labs/scoped-registry-mixin] Investigate making the mixin work when the polyfill isn't loaded #2363
• Issues: [labs/scoped-registry-mixin]
• Docs: README
• npm: @lit-labs/scoped-registry-mixin

Please try @lit-labs/scoped-registry-mixin and tell us about your experience. Leave comments with your thoughts; highlight what issues or missing features you're blocked on; give a link to a project that uses it; etc.

And so we can have some numbers to look at, you can add reactions to this comment to indicate your experience with this package:

🚀 I have tried this package and it works great. I need it. Ship it!
👍 I have tried this package and it seems like a good idea.
😕 I have tried this package and would use it, but it has serious bugs or missing features.
👀 I am interested, but haven't tried the package yet.
👎 I'm not interested in this package.

Note: other reactions like 😄, 🎉, and ❤️ don't mean anything as part of this scheme. You probably mean, and please use, 🚀, 👍, or 👀.

[vekunz]

Hey, I'm glad that Lit is looking into the Scoped Custom Element Registry topic. However, I'm not sure if I fully understand this package yet. What we would need is a way for a Lit-Element not to register in the global registry (window. customElements ), but instead in a scoped Custom Element Registry. This registry could belong to another Lit element or, for example, to a Svelte or Vue component that is rendered as a custom element.

Is the labs package @lit-labs/scoped-registry-mixin the right place for this?

We use Lit in our company to build a component library that is used across many teams (number constantly growing). When a Lit element (e.g., button, checkbox, textfield, etc.) is used by multiple teams, we run into the issue that each custom element name can only be registered once. To work around this, we currently have a small "hack" on every page where we override the global window.customElements.define function to prevent runtime exceptions. But even with this, we could run into version conflicts.

[sorvell]

@vekunz

Is the labs package @lit-labs/scoped-registry-mixin the right place for this?

This package is about scoping the elements used within a hosting LitElement itself. For example, let's say a HostElement needs to render and use a child-element (MyChildElement) inside itself. This package facilitates HostElement having its own scoped registry in which it can use child-element without any collision concerns. How HostElement itself is defined is up to its developer and user and not part of this package.

A good general pattern is to provide a side-effect free module that exports an element class separate from one that defines the element. That way the class can be imported and easily used in a scoped registry, either in conjunction with this package or manually.

This registry could belong to another Lit element or, for example, to a Svelte or Vue component that is rendered as a custom element.

I just want to note that frameworks like Svelte and Vue will likely need to add specific support for scoped registries. This is because creating elements with specific registries is opt-in: document.createElement(tagName, {customElementRegistry})...

[vekunz]

For Svelte I started a disussion there too sveltejs/svelte#18148.

[LorenzKahl]

Scoped Custom Element Registries (SCER 😉) is in interop 2026 and Firefox 150 has just shipped basic support for it behind a flag. So hopefully SCERs will be baseline really soon (like next year-ish).

I'm a bit concerned about the non-standard way the Lit-mixin (i.e. the open WC stuff under the hood) currently handles the registration. A polyfill is needed even for browsers that actually DO support the SCER features as specced - like Chrome and Safari.

If I use this in my design system library to get crossbrowser support today, will I always need the polyfill for it to function? In other words what's the path for this mixin regarding the removal of the polyfill?

Thanks!