Side effect in bundled code `ie(["click", "keydown"]);`
I'm trying to import types from a lib I'm building that contains a Solid.js component. However, when building using a vanilla Vite + Solid setup, the lib's build output has a top-level call to
ie(["click", "keydown"]);
. In turn, this call is added to the output build of the second package. Where is this coming from? Can Solid.js be fixed to not produce these top level function calls?21 Replies
This is what gets added to the second package when importing only types from the first (which has the Solid.js component),
are you using
import type {} from "package"
?
that should prevent the package's code from actually being imported, unless you're importing it somewhere else
also if you're developing a package and not an app, you shouldn't be bundling dependenciesYes, or rather, the equivalent
import { type Foo } from "package";
The snippet above gets included b/c it's considered a side effect regardless of what gets imported
I believe the first (library) package has to contain some Solid.js code because I'm building a web component with Solid.js and solid-element
(https://github.com/solidjs/solid/tree/main/packages/solid-element#readme)
The web component is available to consumers, as well as some typesyeah since it's a package you'll want to only distribute your package's code, bundling in solid and solid-element and everything else should be left up to the builder used by the end user
for making solid libraries i like to use tsup + this preset rather than vite, it makes sure that only your library's code is built + adds the appropriate exports
Thanks for the recommendation!
i'm not too familiar with web components but this is something you'd consume with an npm install and a js import yeah?
I guess I was trying to provide a fully functional web component, hence it feels weird that consumers have to import solid -- they may not even be able to if they're in a pure web environement
Essentially, the web component is packaged and ready to be included in any HTML doc without requiring external dependencies
correct
I think it would be fair to say it's not a solid library, it's a lib that contains a web component that just happens to be built with Solid.js
hmm, that sounds more similar to the app than library use case since they should be standalone web components. you probably do want to bundle in solid in that case
I think so too 😅
in that case what's wrong with the sideeffect being included?
Great question!
Next.js 😮💨
ffs
i thought web components were isolated or something?
Some users are rendering the web component using Next.js, which when rendering on the server errors out due to
window
being included
Yes, they are isolated, but the bundle contains those pesky ie()
callsomg ssring a solid webcomponent and getting a window undefined error is the most obscure problem ever
since solid requires different compilation for client and server
yeah i have no idea what you'd do about that haha
When the component is simple, there are no issues
When the click handlers start to get added, that's when Solid.js generates side effect functions that then interfere with Next.js
yeahhh, those listeners wouldn't be added in the version compiled for server
Alright, maybe I have to look into that, although I'm leaning towards dropping Next.js support, b/c consumers need to be able to freely import the bundle on the browser
Much appreciate your help @Brendonovich 🙏
yeah on the browser it should be fine, you'd be missing ssr support in general though rather than just nextjs support
maybe you'd have to require that next/dynamic is used to make it client only
Yeah, I'll add that to the docs and call it a day
even with solid start you'd need to use clientOnly
Fixed it! Switched from synthetic events (
on__
) to native events (on:__
)