@rsbuild/plugin-solid — SSR with multi-environment builds requires manual workarounds

[DEliasVCruz]

Hey! I've been building a SolidJS SSR app using Rsbuild's multi-environment setup (web + node targets) and ran into some friction with @rsbuild/plugin-solid that I wanted to bring up.

The setup

Pretty standard SSR architecture — two Rsbuild environments:

environments: {
  web: {
    source: { entry: { index: "./src/entry-client.tsx" } },
    output: { target: "web" },
  },
  node: {
    source: { entry: { index: "./src/entry-server.tsx" } },
    output: { target: "node" },
  },
}

The client entry calls hydrate(), the server entry calls renderToStream().

What went wrong

My app kept crashing with ReferenceError: window is not defined. Which was odd considering I was following what was in the solid plugin documentation https://rsbuild.rs/plugins/list/plugin-solid; and my implementation was not doing anything crazy. So I asked claude to lend me a hand.

I found out that out of the box, pluginSolid() applies the same babel-preset-solid options to both environments. For SSR you need generate: "ssr" on the node side and generate: "dom" on the web side, but there's no way to express that with a single plugin call.

The bigger issue was @solidjs/router and @solidjs/meta. These packages ship a "solid" export condition that points to raw JSX source (dist/index.jsx), and a "default" that points to pre-compiled client-only JS. For SSR, you need the JSX source so babel-preset-solid can compile it with generate: "ssr". But the plugin doesn't add "solid" to rspack's resolve.conditionNames, so the pre-compiled client code gets bundled into the server and it's what leads to a crash.

Claude being the code generation hungry beast that it is initally wrote for me a ~50 line custom rsbuild plugin to handle this (manually aliasing packages, adding extra babel rules, walking the rspack config to patch presets). It worked but was ugly and fragile.

The workaround I landed on

After giving it more thought and asking claude to go through the source code of the plugin solid. It turns out Rsbuild's per-environment config handles this cleanly once you know the right knobs:

export default defineConfig({
  plugins: [
    pluginBabel({ include: /\.(?:jsx|tsx)$/ }),
    pluginSolid({ solidPresetOptions: { hydratable: true } }),
  ],
  environments: {
    web: { /* ... */ },
    node: {
      plugins: [
        // Override babel-preset-solid for the SSR build
        pluginSolid({ solidPresetOptions: { generate: "ssr", hydratable: true } }),
      ],
      resolve: {
        // Resolve @solidjs/* to their JSX source so babel can compile for SSR
        conditionNames: ["solid", "node", "import", "module", "default"],
      },
      // ...
    },
  },
});

One gotcha: conditionNames replaces rspack's defaults entirely, so you must include "node" — otherwise solid-js itself resolves to its browser bundle and you get the same window is not defined crash.

Why I think this could live in the plugin

For comparison, vite-plugin-solid handles both of these automatically — it adds the "solid" export condition and detects SSR mode to switch generate. Users don't have to think about it.

@rsbuild/plugin-solid could do the same:

1. Always add "solid" to conditionNames (this is safe — packages without the condition just fall through to the next one)
2. When the environment target is "node", set generate: "ssr" in babel-preset-solid automatically

This would make the "just works" experience match Vite for SolidJS SSR, which is a common use case now that Rsbuild has the multi-environment API.

I realize SSR with Solid on Rsbuild is probably a niche setup right now, but the fix is small and the current DX is pretty rough — you either have to know about conditionNames and per-environment plugins (which aren't documented for Solid), or write a custom plugin to patch the babel config at runtime.

Happy to put together a PR if this sounds reasonable. Would love to hear if others have hit this or if there's a better approach I'm missing.

[chenjiahan]

Thanks for the detailed write-up! This makes sense to me.

I agree we can consider two improvements:

1. When the environment target is node, set generate: 'ssr' by default
2. Add the solid condition for Solid SSR resolution

A PR would be welcome ❤️