solidjs / solid-start

SolidStart, the Solid app framework
https://start.solidjs.com
MIT License
5.01k stars 373 forks source link

[Bug?]: Importing `@kobalte/core` in workspace packages imports `esm` bundle instead of `source` #1390

Closed Brendonovich closed 3 months ago

Brendonovich commented 5 months ago

Duplicates

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:

  1. Go to https://stackblitz.com/edit/vitejs-vite-qjqrgc?file=package.json
  2. Observe Kobalte's dist/esm being loaded on the server image

Context 🔦

No response

Your environment 🌎

No response

Brendonovich commented 5 months ago

Adding @kobalte/core to the dependencies of the app fixes this, no need to import it in the app or anything.

ryansolid commented 5 months ago

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.

Brendonovich commented 5 months ago

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.

ryansolid commented 5 months ago

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.

ryansolid commented 5 months ago

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.

ryansolid commented 3 months ago

Yeah I think this is module behavior type stuff that we won't be touching. Since you have a fix I'm closing.