Hydration bug (build only) with components from linked dependency

[aeplay]

I kept running into hydration issues in my production build of a mostly static site based on the with-tailwind template (SSR yes, TS yes). Dev server always works fine.

The only thing that seems special about my setup is that I import some components from a linked dependency in the same monorepo (using "link:../component-lib" syntax in package.json).

When I manually pull in the components so they're just local, the production build hydrates correctly.

I created a minimal reproduction of the whole setup in https://github.com/aeplay/solid-start-linked-hydration

You can toggle between the two scenarios by un/commenting these lines:

https://github.com/aeplay/solid-start-linked-hydration/blob/3049243436f523111fd550b2d0ccec0d196e82cc/app/src/routes/index.tsx#L1-L7

This is what the dev server renders (yarn dev):

This is what happens in the production build (yarn build && yarn start)

As you can visually see, on hydration, it seems to insert a copy of the preceding MiniStory container into the <em> element inside the MiniStorys that contain an <em>. (Before hydration, the server-rendered HTML looks correct)

In my more complex actual app, I also get lots of errors trying to read nextSibling of null, I guess this minimal scenario is a lucky one where hydration actually finds another (albeit wrong) element to attach to.

Since this differs between dev and build and is related to dependencies, I wonder if this is a side-effect of #127 ?

Thank you for your help.

[marbemac]

I'm running into something very similar to this as well - @aeplay were you able to find a workaround by any chance?

// basic component in a separate package in our monorepo
export const Box = (p: any) => {
  return <div id="COMP_FROM_LOCAL_PACKAGE" {...p} />;
};

Just taking the solid-start bare boilerplate and wrapping the body content in root.tsx with the Box component imported from the separate monorepo package results in a blank screen when running solid-start start (but works fine with solid-start-dev).

What's rendered on the server (javascript off):

Turning javascript back on and reloading the page - once it picks up on the client, it turns into this:

Weirdly two title tags in head, and obviously all the content was wiped.

This is on solid-start v0.2.11 with the latest start-node adapter (also tried with cloudflare pages adapter, same thing).

[marbemac]

Hmm - setting dev: true in the vite config causes the issue to disappear, although I'm not sure what implications are for prod build 🤔.

---

Edit: Passing false to optimizeDeps.disabled also seems to resolve the issue (without having to pass dev: true to the solid plugin. Again, not sure re other side effects / safety of this option though.

[ryansolid]

There is a lot of awkwardness with optimize deps and not which led us to use a plugin created for SvelteKit to walk through dependencies and find which ones have Solid JSX etc.. I'm gathering link completely is ignored by this walk.

We needed to do this all originally because we needed to set JSX to optimize to dedupe but needed to have the specific files all reject other ESBuild would output React JSX. We now in SolidStart have a Solid ESBuild plugin so ESBuild works fine. Maybe we need to just always package ESBuild Solid with our Vite plugins.

[marbemac]

Yeahh, and in fact optimizeDeps ended up resulting in a separate issue. The shared component lib has solid-js in it's dependencies (same version as the app itself), which perhaps is resulting in multiple solid-js getting included, not quite sure TBH. Digging in a bit more.

[0-don]

yes having the same issue but with optimizeDeps it works but the bundle size increases drastictly

[ryansolid]

In setting up for SolidStarts next Beta Phase built on Nitro and Vinxi we are closing all PRs/Issues that will not be merged due to the system changing. If you feel your issue was closed in mistake. Feel free to re-open it after updating/testing against 0.4.x release. Thank you for your patience.

See #1139 for more details.