SolidJS•9mo ago

How do you preserve reactivity across package boundaries?

I've spent most of the day trying every way I could think of to resolve an issue where my components stopped reacting to signal updates when I refactored them into a separate library. The components render fine, they just never receive updates. If I copy the exact code back into the main application package, it behaves as expected. The parent application is being built with vite and the vite-preset-solid plugin. The component library package is npm linked into the application. Here are a few of the methods I attempted that seem like they should have worked: - Using tsup with the solid preset to produce raw JSX files and configure the package exports - Attempting to directly import the tsx files from the library package - Using vite and tsconfig path aliasing to point directly to the tsx files in the component library's repo directory. - symlinking the component library's src folder into a subfolder of my application package's src folder and importing the TSX files from where. I'm sure there's something I'm missing in the build pipeline that's somehow preventing solid from seeing the JSX, but I can't for the life of me figure out what it is or what other steps I could take to investigate further. Any help or advice much appreciated!

3 Replies

thetarnav•9mo ago

those kind of issues almost always come from 1. one file is using server runtime while the other is using client runtime (this used to happen with jest/vitest some time ago) 2. one file is using one solid version, while other is using another version (this is sometimes caused by package managers, and usually solid will display a warning "Two versions of solid detected" or something like this) generaly study the sources panel in devtools and try to figure out what is importing what to quickly confirm that two solid versions are being using you can do this

// both in the package and app
import {createSignal} from "solid-js"
if (global.createSignal) {
  if (global.createSignal === createSignal) console.log("Runtimes are the same")
  else throw Error("Runtimes are different")
} else {
  global.createSignal = createSignal
}

// both in the package and app
import {createSignal} from "solid-js"
if (global.createSignal) {
  if (global.createSignal === createSignal) console.log("Runtimes are the same")
  else throw Error("Runtimes are different")
} else {
  global.createSignal = createSignal
}

cerealklrOP•9mo ago

1. Thanks, that could be a lead. The parent application is an obsidian plugin which runs in electron. It's maybe possible that's leading us down some SSR path I guess (?) 2. Interesting, I use vanilla npm for both and made solid a peer dependency I don't see any obvious printed warnings from solid about multiple versions in obsidian's dev console clever! I'll give that a shot, thanks Indeed that seems to be the problem! I'll poke around in the library to see why it's still dragging a version of solid along and update when I figure it out (or if I need more help). Thanks for the great advice! that took a while even after knowing the problem, but eventually determined that peer dependencies and linked packages using vanilla npm is still problematic. The only real solution I found (outside of switching to one of the other package managers) was to npm link the parent project's solid-js package from the child module o.0 Regardless, everything's up and running now, thanks!

Alex Lohr•9mo ago

It still depends on the bundler, especially with npm's sub dependency handling.

Gaming

Programming

How do you preserve reactivity across package boundaries?