[Bug] changes are not picked up by refresh/hmr/re-running storybook

[43081j]

What version of vite are you using?

6.5.15

System info and storybook versions

├── @storybook/addon-essentials@6.5.15
├── @storybook/builder-vite@0.2.6
├── @storybook/web-components@6.5.15

Node 17, MacOS.

Describe the Bug

First of all, i'm aware 7.x is on the way but we can't really upgrade yet since it isn't out of beta.

I have the following storybook config:

module.exports = {
  stories: ['../lib/**/*.stories.js'],
  staticDirs: [
    {
      from: '../fonts',
      to: '/fonts'
    }
  ],
  addons: [
    '@storybook/addon-essentials'
  ],
  core: {
    builder: '@storybook/builder-vite',
    disableTelemetry: true
  }
};

I use web components and point storybook at the build output (not at the typescript sources, i forget why).

If I then npx start-storybook and in another terminal npx tsc -w, storybook correctly loads and displays my stories.

If I then change a component, no reload happens, hmr or not. I can try hard reload the page (no client cache) and the same unchanged component will render. I can even try stopping and starting storybook, and the same unchanged component will render.

I can see my change in the build output, and I can see tsc responding to file changes and triggering a build.

The only way we can get it to load the updated component seems to be by telling it not to use a cached manager.

Console errors that may be relevant, something somewhere is trying and failing to load some webpack HMR endpoint:

GET http://localhost:6006/__webpack_hmr 404 (Not Found)

Could be some kind of duplicate of #387

Link to Minimal Reproducible Example

No response

Participation

• [X] I am willing to submit a pull request for this issue.

[IanVS]

Can you put together a reproduction we can look into? It sounds like you have a pretty unique setup.

[43081j]

similarly, it seems the source maps are hooked up as webpack:// paths, which of course don't resolve:

Could not load content for webpack:///src/my-button/MyButton.ts (Fetch through target failed: Unsupported URL scheme; Fallback: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME)

keep in mind we don't use webpack ourselves.

& sure i will try get a repro together. i was seeing if i could track the problem down a bit more first but things get sketchy in the innards of vite.

[IanVS]

Webpack is still used for the "manager" part of storybook, even in the vite builder. That was removed in 7.0. it shouldn't be being used to load your story files or components though, so that error is definitely odd, and probably a good place to dig in.

[43081j]

yup i recall but definitely shouldn't be going anywhere near the component sources.

weirdly when i try setup a reproduction i run into a different problem preventing me from testing this one... storybook seems to think the manager config has always changed, and will rebuild the manager each time I launch it because of that.

ill debug that first and see where i get to

[43081j]

aha @IanVS the constantly changing manager build is because of this it seems (presumably exists in the webpack4 builder somewhere too?):

https://github.com/storybookjs/storybook/blob/1727d4b2c4453d7724eb69d116325cca7167a5b3/code/lib/builder-webpack5/src/preview/iframe-webpack.config.ts#L245

the SERVER_CHANNEL_URL is the port we run storybook on. if you don't set a port, it'll change every time, which means your stringified config also changes every time.. leading to storybook hitting this logic:

https://github.com/storybookjs/storybook/blob/feab19dad03201d094000c656bcb4559294b3914/lib/manager-webpack4/src/utils/manager-cache.ts#L26-L30

since the two config strings won't be equal (the url will have changed port)

[43081j]

@IanVS it turns out the node_modules/.cache directory had a previously cached copy of the iframe.html.

switching between the webpack builder and the vite builder apparently didn't clear this cache, so the serve-static middleware basically reloaded the cached HTML from disk. that resulted in loading webpack and everything else it comes with.

in that case, i don't think this is a bug with the builder necessarily, but with storybook itself. storybook should clear the cached iframe if the builder has changed, i think.

let me know what you think

[IanVS]

Normally it should clear the cache whenever you change the .storybook/main.js file, yes. If you can create some steps that reproduces the issue you're having, I'd suggest opening an issue in storybook, yes.

Is everything working correctly now that you've cleared out the cache?

[43081j]

yup no worries, i have a repro now!

ill open two issues over in the storybook repo 👍

will close this, thanks for the help too

edit: in actual fact, 7.x doesn't seem to have either issue. so i may leave it as-is, in the hope the upgrade just fixes everything once it gets out of beta