[Bug]: RSC stories that use "react-server" exports do not get bundled correctly about storybook HOT 5 OPEN

@kasperpeulen @valentinpalkovic @ndelangen can we get storybook to bundle react-server code into our browser bundles by default?

from storybook.

Thanks for the detailed issue! @shawngustaw

For now I can recommend the following work-around:

// main.ts
  webpackFinal: (config) => {
    config.resolve?.conditionNames?.unshift('react-server')
    config.resolve!.alias = {
      ...config.resolve?.alias,
      'client-only': false
    }
    return config;
  }

I'm going to investigate how to best solve this in general.
It is kind of tricky. In storybook, we do run the async RSC components as async client components.
And we recommend people to use module mocking to avoid running node specific code in the browser.

This is our RSC demo that uses an in-memory database in storybook:
https://github.com/storybookjs/storybook-rsc-demo/blob/6cca874e7736d70d36d770b42dfc6ccf98ce125a/package.json#L12-L15

Running both the server and client stuff in one environment (the browser) has a lot of advantages as it comes to a true unit-testing experience. It is super fast, and you can both set a server mock, spy on a function and access a dom element in the same unit/component test:
https://github.com/storybookjs/storybook-rsc-demo/blob/main/app/note/edit/page.stories.tsx

My feeling is that the best thing we can do, is trick the bundler, to think of storybook as both a react-server and a react-client in the same time, which is what the above tries to achieve.

from storybook.

@kasperpeulen Thanks so much for tracking that down. If we can't safely apply this configuration automatically by default, at least we can add that configuration (and its Vite equivalent) prominently in our RSC docs once that's a thing. cc @kylegach

from storybook.

@shilman After thinking a bit more about it. Maybe we should just do add it to the nextjs framework by default when experimentalRSC: true is set to the 8.2 alpha release. And see what it breaks.

I can imagine that in theory this does unwanted stuff, for example, when a library exports both a RSC and client variant of the same component. I only don't know if this is really what the ecosystem is gonna do, or that this is just an imaginary example.

In this worst case scenario, I think we should recommend people to have 2 storybooks. One that is for RSC components, and one for client only components.

from storybook.

Good call @kasperpeulen ! @shawngustaw is that a change you might be able to contribute?

from storybook.