You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, some dependencies are either imported twice or bundled incorrectly, which unnecessarily increases the final bundle size, and could lead to bugs with global state.
In particular, I noticed this because working on some new components I was getting errors saying that the components were already defined when I tried to used them. We're building components using Lit, and the default @customElement decorator registers a custom element globally without conditionals. In contrast, the components we had been defining ourselves were defined like this:
At first glance, it seems like this is good, because it gets rid of the error. But what it's actually doing is silencing an issue that should be solved instead. If the code to register a component is running twice, that usually means that the code has ended up twice in the final bundle.
It's not straight forward to solve given the current architecture and bundling configuration, but some first steps towards solving this have been made in SolidOS/solid-ui#780. However, this is an issue with the entire SolidOS stack, not just the solid-ui package. So I'm opening this issue to track the problem until it's solved.
This happened before, if you look at the legacy code we already had those "if custom element registered" checks. I haven't tracked a specific example, but as soon as you remove those ifs you're going to get an error so you can see it there.
I think the main reason why this happens is that some packages are not bundled correctly, and end up bundling more than they should. For example, if a pane doesn't declare "solid-ui" as an external dependency, the component code will end up in the dist files of the pane. And it's going to work at runtime, because we have those ifs. But we'll still be duplicating the components source.
In any case, as I mentioned in the issue description I don't think this is an easy problem to fix because it probably involves fixing the bundle configuration for multiple packages in our stack. But it's very easy to reproduce, just remove those ifs (that shouldn't be there) and you'll start seeing errors. That should be helpful to track down which packages are to blame and how to start fixing it.
globals.ts imports * as UI from 'solid-ui'
index.ts also imports solid-ui/components/header
index.esm.js already imports ./header/index.esm.js
That means the header web component is being loaded twice in the module graph:
once via the solid-ui package import
again via the direct solid-ui/components/header side-effect import
Why this is likely the bug
solid-ui/dist/index.esm.js already includes header registration as part of the main package bundle
the explicit solid-ui/components/header import is therefore redundant
webpack.config.mjs defines a UI$ alias, but that alias only matches the module name UI, not solid-ui, so it does not prevent this duplicate import path
We cannot delete v2 components because solid-ui/components/photo-capture is used in profile-pane -> we need to properly create a web component for it or move the code. @NoelDeMartin I task you for this - ticket: SolidOS/solid-ui#821
The header and footer v2 components are in use in solid-panes.
Activity
timea-solid commentedon Jun 29, 2026
Can you give some example which dependencies are imported twice? Is this since we moved to web components or is it from before?
NoelDeMartin commentedon Jun 29, 2026
This happened before, if you look at the legacy code we already had those "if custom element registered" checks. I haven't tracked a specific example, but as soon as you remove those ifs you're going to get an error so you can see it there.
I think the main reason why this happens is that some packages are not bundled correctly, and end up bundling more than they should. For example, if a pane doesn't declare "solid-ui" as an external dependency, the component code will end up in the dist files of the pane. And it's going to work at runtime, because we have those ifs. But we'll still be duplicating the components source.
In any case, as I mentioned in the issue description I don't think this is an easy problem to fix because it probably involves fixing the bundle configuration for multiple packages in our stack. But it's very easy to reproduce, just remove those ifs (that shouldn't be there) and you'll start seeing errors. That should be helpful to track down which packages are to blame and how to start fixing it.
timea-solid commentedon Jun 29, 2026
What AI found:
Findings
timea-solid commentedon Jun 30, 2026
Atempt to fix in: SolidOS/solid-ui#818
timea-solid commentedon Jul 1, 2026
Because the interface here in GitHub does not work :
In order to delete the v2 components in solid-ui we need to first merge: SolidOS/profile-pane#402
timea-solid commentedon Jul 1, 2026
We cannot delete v2 components because solid-ui/components/photo-capture is used in profile-pane -> we need to properly create a web component for it or move the code. @NoelDeMartin I task you for this - ticket: SolidOS/solid-ui#821
The header and footer v2 components are in use in solid-panes.
timea-solid commentedon Jul 3, 2026
This deletes the footer: SolidOS/solid-ui#829
timea-solid commentedon Sep 29, 2026
We do not have the problem of multiple loading of web components anymore. @SharonStrats I wthink you can write here more about the solution.