[Bug] HMR for manager code doesn't work, so addon-kit's watch mode doesn't do as much as expected

[morewings]

Describe the bug

Watch mode (aka live reload) is broken for me. My setup: macOS 12.6.3, Node v16.14.0. When I change the code, Storybook in browser doesn't show the change.

Maintainers' notes: the issue is not with build:watch in the addon-kit but with the lack of HMR for manager code in Storybook itself.

Steps to reproduce the behavior

1. Clone this repo on macOS 12.6.3, Node v16.14.0.
2. Run yarn install
3. Run yarn start
4. Change any displayable value in src/Tool.tsx
5. Save file
6. Elevator music playing
7. Nothing is changed in browser.

Expected behavior

Changes in the code are reflected in running Storybook instance without reloading Storybook manually.

Environment

• OS: macOS 12.6.3
• Node.js version: v16.14.0
• NPM version: 9.2.0
• Browser (if applicable): chrome, safari, firefox
• Browser version (if applicable): n/a
• Device (if applicable): MacBook Pro 2015

Additional context

No other context. Thanks for your work, colleagues.

[SpookyJelly]

Same happens here. with machOS 12.6, Node v16.x.

I have to re-build everytime the project to see changes and it is really pain in my ass

P.S) I am using this addon kit without ts-emit. is that a reason this happens?

[morewings]

@SpookyJelly can you elaborate tsemit part? Haven’t seen the docs for that.

[SpookyJelly]

@morewings Sure, I followed the tutorial below. In here, author used the eject command to convert the boilerplate code to JavaScript.

https://storybook.js.org/tutorials/create-an-addon/react/en/getting-started/

[winkerVSbecks]

This is a regression for sure. We dropped the hmr code from index.ts:

if (module && module.hot && module.hot.decline) {
  module.hot.decline();
}

The reason we dropped hmr was to avoid shipping addons with hmr. I'll look into adding it back in for dev mode.

[winkerVSbecks]

Investigated this a bit more, and turns out that this is a limitation with Storybook 7.

In SB7, the manager is pre-bundled. The watch mode works and the generated code is updated, but Storybook doesn't rebuild the manager. In SB6, we could disable the cache to refresh the manager on each build.

Prebundling was a major perf boost for Storybook users, but unfortunately, it made addon development a bit more challenging. I'm looking at other options. Will let you all know if I figure something out.

[SpookyJelly]

Investigated this a bit more, and turns out that this is a limitation with Storybook 7.

In SB7, the manager is pre-bundled. The watch mode works and the generated code is updated, but Storybook doesn't rebuild the manager. In SB6, we could disable the cache to refresh the manager on each build.

Prebundling was a major perf boost for Storybook users, but unfortunately, it made addon development a bit more challenging. I'm looking at other options. Will let you all know if I figure something out.

I hope the research goes well. SB7 is really awesome and I don't want to go back SB6 :(

[winkerVSbecks]

This should only impact you during addon development. Not when using the addon.

[morewings]

@winkerVSbecks I think @SpookyJelly is talking about developer experience. I can make addon without live reload, like in good old times. But it’s wrong. The mission of Storybook is to make devs and designers life easier, not harder.

[ericclemmons]

Do we have any ideas how to work around this with SB 7? I've tried several things on my end, but they've all failed. Local addons are still parsed (I'm using .tsx), but the HMR isn't there...

[AriPerkkio]

Adding custom tsup hook that restarts the storybook dev server improves developer experience a bit. You'll still have to manually refresh the browser, but at least changes are reloaded automatically:

import { defineConfig } from 'tsup';
import { exec } from 'node:child_process';

export default defineConfig((options) => ({
  async onSuccess() {
    if (!options.watch) return;

    const subprocess = exec('pnpm run storybook --no-open');
    subprocess.stdout?.on('data', (data) =>
      console.log(`[storybook]: ${data}`)
    );

    return function cleanup() {
      subprocess.kill();
    };
  },
...

[JoltCode]

This still seems to be an issue ^, it's a real pain!

[winkerVSbecks]

@integrayshaun it's worth investigating @AriPerkkio's suggestion

[Lighttree]

Am I right that addon development is broken for SB7 at the moment? I'm just trying to migrate our internal addon to SB7 based on this doc: https://storybook.js.org/docs/addons/writing-addons and it seems that even in the example watch doesn't work properly.

[SpookyJelly]

It's been a year and I don't think it's been resolved yet, has anyone found another way?

[enix79]

Still an issue in 2025

[enix79]

@AriPerkkio 's solution doesn't work for me. It tries to open another storybook instance on the same port. Then I get this error:

Port 6006 is not available. Would you like to run Storybook on port 6007 instead?

It's really painful to develop SB addons without any HMR solution.

As far as I can see it's just an issue if you use the addon-kit template. Creating a project from scratch may do the trick.

[Sidnioulz]

Hey folks,

I've discussed this a bit with maintainers and here's where we're at:

• Watch mode in the addon-kit works as expected: it watches your addon source code and rebuilds it
• As pointed out, the manager is pre-built since SB7, and it is not automatically re-built, for performance reasons; because of that, you still have to reload Storybook after the addon code has been rebuilt
• The Core Team believe it's possible to implement pseudo-HMR by having esbuild watch relevant source files (identified by the managerEntries of loaded addons and likely the manager* files in .storybook) and rebuild the manager when they change, so that Storybook would no longer need to be manually restarted
• The relevant code to contribute this change is here
• You would then need to hard reload the window in your browser; we likely couldn't achieve true HMR and only reload the pieces of code that have changed because managerEntries contain imperative code that may have side effects

Contributions are welcome. The Core Team expect this contribution to be feasible by an external contributor, but difficult. Reach out on Discord if you need help with contributing.

I'm going to update the issue a little bit to reflect on what's working and what needs to be addressed.

[enix79]

@Sidnioulz, how is this pre-bundling exactly executed? Via vite?

Wouldn't it be possible to turn pre-bundling off in a dev environment/mode?

[Sidnioulz]

@Sidnioulz, how is this pre-bundling exactly executed? Via vite?

Wouldn't it be possible to turn pre-bundling off in a dev environment/mode?

Not sure how it's done. Disabling this would undo the major performance benefits of Storybook 7, it would make launching Storybook much slower.

The Core Team's proposal is to specifically watch and rebuild the addon files whilst keeping much of the manager build caching logic in place, if I understand correctly.

[winkerVSbecks]

Pretty sure it's not vite. It's using esbuild directly. There are two different process. The prebuild one runs at build time and then the server starts up.