[Bug?]: Importing `@kobalte/core` in workspace packages imports `esm` bundle instead of `source`
Duplicates
- [X] I have searched the existing issues
Latest version
- [X] I have tested the latest version
Current behavior 😯
Importing @kobalte/core in a workspace package which is imported by a solid start app with ssr: true causes the esm distribution of kobalte to be loaded on the server which uses solid's client JSX transform, rather than the source distribution being loaded so that the server JSX transform can be used.
Expected behavior 🤔
source to be used on the server so that kobalte works on client and server.
Steps to reproduce 🕹
Steps:
- Go to https://stackblitz.com/edit/vitejs-vite-qjqrgc?file=package.json
- Observe Kobalte's
dist/esmbeing loaded on the server
Context 🔦
No response
Your environment 🌎
No response
Adding @kobalte/core to the dependencies of the app fixes this, no need to import it in the app or anything.
So is there an issue here? What I'm understanding is your library isn't compiling down so kobalte is a dependency of the app and needs to be there. Like either you are bundling it into your lib or the app needs it as a dep. When the app pulls the source in it looks in its own node modules not the libs I believe.
When the app pulls the source in it looks in its own node modules not the libs I believe.
Ahh I see, if this is expected behaviour then there's no issue here. Assumed it would work since it does in our React monorepos. Though in the repro kobalte is being loaded from the monorepo's node_modules, not the libs, and yet it still uses the esm export.
Oh in the stackblitz example there were no node_modules top level only in each project so I didn't see that behavior. If they are hoisted I wouldn't expect them to resolve differently as generally they start from the entry and move up the folder tree looking for node_module folders. Given that our plugins uses solid export condition (and I assume Kobalte does as well, other wise it would work directly) I'm not sure why the location of the node_modules would make a difference. This could be the interaction of certain things I'm not aware of but really the only difference I can see is that in React the components would be pre-compiled. Only here would we be importing source, which is just a export condition resolution. So something up with that I guess.
Yeah I don't know what to do with this one, it has to be scope of the processing from Vite/Vinxi I guess. Because like if it is resolving to ESM and not using export conditions it is getting bypassed for some reason. It's possible that vite-plugin-solid's use of vitefu is the only reason it resolves these properly at all and you need to manually add it to an optimize deps list or something like that. But I admit I don't know know which of these things are responsible here.
Yeah I think this is module behavior type stuff that we won't be touching. Since you have a fix I'm closing.