In v6.1.6 storybook react no longer loads. It generates a bad bundle name

[davesag]

Describe the bug

In v6.1.6 storybook react builds but no longer loads in the browser. It generates a bad bundle name

Reverting back to 6.1.4 fixes the problem

To Reproduce

Upgrade a React project that is working under Storybook 6.1.4 and run storybook and you get a blank browser page.

In the console it says

HTTP error: status code 404 could not load http://localhost:6006/xxxblah.bundle.js

Expected behaviour

I expected the storybook to load

System

Environment Info:

System:
OS: macOS 10.15.7
CPU: (16) x64 Intel(R) Xeon(R) W-2140B CPU @ 3.20GHz
Binaries:
Node: 14.15.1 - ~/.nvm/versions/node/v14.15.1/bin/node
Yarn: 1.22.10 - /usr/local/bin/yarn
npm: 6.14.8 - ~/.nvm/versions/node/v14.15.1/bin/npm
Browsers:
Chrome: 87.0.4280.67
Safari: 14.0.1
npmPackages:
@storybook/addon-actions: ^6.1.6 => 6.1.6
@storybook/addon-essentials: ^6.1.6 => 6.1.6
@storybook/addon-links: ^6.1.6 => 6.1.6
@storybook/node-logger: ^6.1.6 => 6.1.6
@storybook/preset-create-react-app: ^3.1.5 => 3.1.5
@storybook/react: ^6.1.6 => 6.1.6

[shilman]

Do you have a repro repo you can share? Unable to reproduce.

Or if not a full repro, what does this part of your package.json look like?

    "storybook": "start-storybook -p 6006 -s public",
    "build-storybook": "build-storybook -s public"

[monkeyinsurgency]

Same issue after upgrading. My package.json looks like:

"storybook": "start-storybook -p 6006 --no-dll",
"build-storybook": "build-storybook --no-dll"

Reverting to 6.1.5 fixes the issue.

[davesag]

Do you have a repro repo you can share? Unable to reproduce.

Or if not a full repro, what does this part of your package.json look like?

    "storybook": "start-storybook -p 6006 -s public",
    "build-storybook": "build-storybook -s public"

It looks exactly like that. Sorry not a public repo. I was able to remove the —no-dll bit when upgrading to 6.1.4 which works fine.

[ghengeveld]

Can someone with this error please share the following:

• Storybook's main.js config
• Storybook's preview.js config
• The start-storybook CLI output

I have upgraded our shapes demo repository to 6.1.4, then to 6.1.6 without any problem. I did notice however, that the cached manager is not busted when upgrading Storybook, which would lead to the preview and manager to be different versions of Storybook. I've opened an issue for that: #13291

To make sure this issue is unrelated to manager caching, please delete node_modules/.cache before starting Storybook.

[shilman]

@ghengeveld to me this looks like a bug with the static route change?!

[ghengeveld]

You mean the -s public?

[shilman]

Your PR in that release changed the code related to the static directory handling, and now a static file is serving incorrectly.

[ghengeveld]

That seems likely, but so far I can't reproduce.

[davesag]

Just tried again with v6.1.7.

• I removed the node_modules/.cache folder.
• confirming my package scripts as follows

    "storybook": "start-storybook -p 6006 -s public",
    "build-storybook": "build-storybook -s public"

running npm run storybook

It builds okay

webpack built 6c4d9ade43c0dc5108cd in 12596ms
╭────────────────────────────────────────────────────╮
│                                                    │
│   Storybook 6.1.7 started                          │
│   14 s for preview                                 │
│                                                    │
│    Local:            http://localhost:6006/        │
│    On your network:  http://192.168.20.23:6006/    │
│                                                    │
╰────────────────────────────────────────────────────╯

but in the browser I just get a blank page.

In the console I see:

Failed to load resource: the server responded with a status of 404 (Not Found)
main.85fc4cce5689ec0a5f0b.bundle.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
vendors~main.e7564fc28a4422efd6b6.bundle.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)
main.85fc4cce5689ec0a5f0b.bundle.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)

The bundle hash is not the same as any of the hashes that the page attempts to load.

.storybook/main.js

const path = require('path')

module.exports = {
  stories: [
    "../src/**/*.stories.mdx",
    "../src/**/*.stories.@(js|jsx|ts|tsx)"
  ],
  addons: [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/preset-create-react-app"
  ],
  webpackFinal: async (config) => {
    config.resolve.modules = [
      ...(config.resolve.modules || []),
      path.resolve(__dirname, "../src")
    ]

    return config
  }
}

.storybook/preview.js

import redux from './redux.decorator'

export const parameters = {
  actions: { argTypesRegex: "^on[A-Z].*" }
}

export const decorators = [redux]

npm run storybook full output

> start-storybook -p 6006 -s public

info @storybook/react v6.1.7
info 
info => Loading static files from /Users/davesag/src/[redacted]/public and serving at /.
info => Using prebuilt manager
info => Loading presets
info => Loading 1 config file in "./.storybook"
info => Loading 7 other files in "./.storybook"
info => Adding stories defined in ".storybook/main.js"
info => Loading Webpack configuration from `node_modules/react-scripts`
info => Removing existing JavaScript and TypeScript rules.
info => Modifying Create React App rules.
info => Using default Webpack setup
webpack built 6c4d9ade43c0dc5108cd in 12596ms
╭────────────────────────────────────────────────────╮
│                                                    │
│   Storybook 6.1.7 started                          │
│   14 s for preview                                 │
│                                                    │
│    Local:            http://localhost:6006/        │
│    On your network:  http://192.168.20.23:6006/    │
│                                                    │
╰────────────────────────────────────────────────────╯

[shilman]

Can you try running with --no-manager-cache?

[jpcmf]

Anybody can help me with this issue?

#13255

[jpcmf]

How to downgrade? Only manually?

[davesag]

Can you try running with --no-manager-cache?

I'll try this later today and report back. Also I see SB is now up to 6.1.9 so will try that too.

[davesag]

Okay I just tried upgrading my project to 6.1.9. Starting up storybook gave the same issue as before - a malformed bundle name (or at least a different bundle hash to the one the system is looking for). Starting it up again however with --no-manager-cache fixes the problem.

Once it works then dropping the --no-manager-cache again works fine, but I'll need to leave it in there for now as other members of the team will also hit the same issue and I'd rather the update just worked invisibly.

[kiily]

I am getting a slightly different error but seems to be related to upgrading. I recently used the auto-upgrade with npx to bump our storybook from 6.0.21 to 6.1.9 and I am getting errors all over the place when I check out one of my stories. Could this be related to the above? I tried the --no-manager-cache to no avail :/

I can confirm that the same issue is on version 6.1.4

[ghengeveld]

@kiily Looks like you've misconfigured addon-backgrounds. It takes an array of values. Most likely you've given it a string, object or null somewhere. undefined would be fine because it defaults to an empty array. Check the docs for details.

This is unrelated to the issue at hand, so if you can't work it out, please open a separate bug report.

[kiily]

Hi @ghengeveld, reverting actually gave me a helpful warning and pointed me in that direction too. I think it's just configured with the old API and hence the error. I will test and report back, will open a new issue if necessary but feels like that should do the trick.

Thanks for the quick reply, keep smashing it guys. Amazing job all around 🎉

[kiily]

@ghengeveld I can confirm that fixes the issue 🙏 Thanks again

[stale]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

[thejustinwalsh]

Okay I just tried upgrading my project to 6.1.9. Starting up storybook gave the same issue as before - a malformed bundle name (or at least a different bundle hash to the one the system is looking for). Starting it up again however with --no-manager-cache fixes the problem.

Once it works then dropping the --no-manager-cache again works fine, but I'll need to leave it in there for now as other members of the team will also hit the same issue and I'd rather the update just worked invisibly.

Just hit this on an upgrade to 6.1.18 and this did the trick for me as well.

[didymu5]

I just want to add that @davesag tip worked for me. After I had did the npx upgrade as suggeted, my storybook dev server was looking for a main.xxx.js bundle that wasn't there. (404) - Once u ran storybook with the suggested tag I was able to get my SB back.

[shilman]

Egads!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.3.0-alpha.44 containing PR #14993 that references this issue. Upgrade today to the @next NPM tag to try it out!

npx sb upgrade --prerelease

Closing this issue. Please re-open if you think there's still more to do.

[aknaut]

I still experienced this problem after updating from 6.3.2 to 6.3.7. Adding the option --no-manager-cache as suggested solved the problem for me.

[huntzinger92]

EDIT: Clearing my browser cache solved the issue. Not sure why, but it seems like storybook doesn't look at the new main.[hash].bunder.js file when the hash changes.

---

I'm encountering this issue in a way that doesn't seem to be related to upgrading storybook. After running npm run storybook (with and without --no-manager-cache flag), I get a blank page with this logged to the console:

main.600d6c919d9f368542ae.manager.bundle.js:1 Failed to load resource: the server responded with a status of 404 (Not Found)

Storybook stuff from package.json (this has not changed):

"scripts: { ... "storybook": "start-storybook -p 6006", "build-storybook": "build-storybook" }

"devDependencies": {
"@storybook/addon-actions": "^6.1.14",
"@storybook/addon-essentials": "^6.1.14",
"@storybook/addon-links": "^6.1.14",
"@storybook/react": "^6.1.14",

main.js:
module.exports = {
stories: ['../src/**/*.stories.mdx', '../src/**/*.stories.@(js|jsx|ts|tsx)'],
addons: ['@storybook/addon-links', '@storybook/addon-essentials'],
};

preview.js:
import MyTheme from '@myTheme';
import { ThemeProvider } from '@material-ui/core/styles';

export const parameters = {
actions: { argTypesRegex: '^on[A-Z].*' },
};

export const decorators = [
(Story) => (
<ThemeProvider theme={MyTheme}>
<Story />
</ThemeProvider>
),
];

Another piece of the puzzle is that, if I run npm install in a feature branch that does not have this issue and then switch over to the problem feature branch without running npm install, storybook runs fine, even though the package.json files are identical. I hit the bug only after running npm install, so it feels like there is some weirdness related to that process. I have already tried deleting node_modules, which did not help.

[idesignpixels]

I had this issue when moving a repo from GH to GL, upgrading to 6.3.8 fixed it for me npx sb@latest upgrade

[totszwai]

I tried all of the suggestion above, didn't work.
Then flushing the browser cache fixed it for me... Wow.

[frbl]

Running now on 6.3.12 on a fresh install (NextJS, TS, Tailwind, Storybook), but doesn't work. Also non of the workarounds mentioned in this thread unfortunately.

No errors in the terminal

╭───────────────────────────────────────────────────╮
│                                                   │
│   Storybook 6.3.12 started                        │
│   5.14 s for manager and 5.08 s for preview       │
│                                                   │
│    Local:            http://localhost:6006/       │
│    On your network:  http://192.168.1.18:6006/    │
│                                                   │
╰───────────────────────────────────────────────────╯

some in the console;

DevTools failed to load source map: Could not load content for http://localhost:6006/index.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
vendors~main.manager.bundle.js:107059 [Violation] 'setTimeout' handler took 53ms
DevTools failed to load source map: Could not load content for http://localhost:6006/react-popper-tooltip.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

[Powerm1nt]

Same issues for me sadly :/

[fllprbt]

Same for 6.4.13. Clearing cache does not help.

[ghengeveld]

@fllprbt Did you trash node_modules and try again? Please create a new ticket for 6.4.13 and elaborate on your exact problem if this is indeed a regression. The issue at hand is closed.

[rwieruch]

Running into the same issue for new builds of my Storybook using v6.5.5 for this project which is hosted over here.

Failed to load resource: the server responded with a status of 404

Every time I push an update, following scripts are running on my server:

git pull --rebase origin master
yarn install
yarn run storybook:build

where the storybook:build script is:

"storybook:build": "build-storybook .storybook --no-manager-cache .storybook/static -o dist",

What I tried:

• Used --no-manager-cache for a while, but it didn't help.
• As @totszwai suggested I always have to bust the browser cache to make it work on my end, but I cannot expect website visitors to do the same.
• I think @huntzinger92 was onto something here as well. For me the browser looks for [*]bundle.js files that are not there anymore. In my case, at this time of reporting, it's looking for https://react-table-library.com/main.5387a4e9.iframe.bundle.js See screenshot, where this one main*bundle file is missing.

Would be super happy seeing this getting solved. At least, if there is nothing we can do from Storybook's side, is there anything that I can clean (e.g. node_modules/.cache) on rebuild to make this go away?