build-storybook --output-dir flag does not correctly set root path for static files

[mrmartineau]

Describe the bug
When running build-storybook -s ./static -o public/storybook for example, you would expect, when serving the site (Gatsby in my case) from the public directory that visiting /storybook would show the statically-built storybook - it does not.

The problem that I'm getting is that even though the output directory is public/storybook, storybook itself references its dll or .js files from the root of the public directory.

I get errors like this in my browser console:

GET http://localhost:5000/runtime~main.2469e7554f58d55ce32e.bundle.js net::ERR_ABORTED 404 (Not Found)

The storybook files should be located within the public/storybook directory, and the page would work

http://localhost:5000/storybook/runtime~main.2469e7554f58d55ce32e.bundle.js

To Reproduce
Steps to reproduce the behavior:

1. Run build-storybook -s ./static -o public/storybook
2. View the generated files in the public/storybook directory
3. Serve the /public directory using something like serve e.g. serve public
4. See that you can't view the storybook and view the errors in the console.

Expected behavior
The Storybook should work as per usual

Screenshots

Code snippets
n/a

System:

I am running 6.0.10 of every storybook package.

  "devDependencies": {
    "@babel/core": "^7.11.1",
    "@storybook/addon-actions": "^6.0.10",
    "@storybook/addon-essentials": "^6.0.10",
    "@storybook/addon-links": "^6.0.10",
    "@storybook/react": "^6.0.10",
    "@types/node": "^14.0.27",
    "@types/react": "^16.9.46",
    "@types/react-dom": "^16.9.8",
    "babel-loader": "^8.1.0",
    "babel-preset-react-app": "^9.1.2",
    "eslint": "^7.7.0",
    "eslint-config-prettier": "^6.11.0",
    "eslint-plugin-prettier": "^3.1.4",
    "eslint-plugin-react": "^7.20.6",
    "eslint-plugin-react-hooks": "^4.0.0",
    "prettier": "^2.0.5",
    "react-is": "^16.13.1",
    "storybook-addon-color-mode": "^1.2.5",
    "storybook-addon-paddings": "^2.0.2",
    "typescript": "^3.9.7"
  }

I tried running the command (npx sb@next info) but it threw an error (this issue is tracking that bug):

Additional context
Add any other context about the problem here.

[shilman]

Don't use serve with storybook. Try http-server and run it from within the built directory.

[mrmartineau]

@shilman thanks for that. Using http-server does indeed work. Can you explain why serve does not?

[shilman]

Serve does some weird automatic mangling of URLs like iframe.html => iframe ... which storybook does not like

[mrmartineau]

huh.. didn't realise that. Good to know.

[rezavation]

Serve does some weird automatic mangling of URLs like iframe.html => iframe ... which storybook does not like

I switched from using serve --listen 9009 storybook-static to http-server storybook-static --port 9009 because I was getting the issue you described, where I would visit localhost:9009/iframe.html?id=components-alert--success and it would redirect me to localhost:9009/iframe. But i'm still having this issue, even with http-server. @shilman what is the endorsed way of serving up your storybook-static, and being able to directly open a story?

This is the same issue that was referenced in #6030

using storybook 5.3.9

[sneko]

I'm facing weird situation like mentioned. The /iframe.html is a 301 redirection to /iframe (which is 404). Here the example:

So it's exactly what you were mentioning @shilman (#12052 (comment)) except I'm using storybook dev with Vite.

This strange thing was also mentioned at #6030 (comment) but since he is using http-server I guess that's when doing storybook start... which is not my case.

Any idea how to solve this?

Important:

• when going onto http://localhost:6006/iframe.html directly in my browser URL bar the 301 does not apply so it works, the issue seems only active when used through an iframe (weird, never saw a conditional 301...)
• when going to the local network address http://192.168.1.13:6006/ to see the Storybook frame (so having http://localhost:6006/iframe.html inside an iframe), it works perfectly (due to no 301 redirection)...

If I do a refresh cmd+shift+R, it clears the cache, and the 301 no longer applies. Also, when restarting storybook dev I may not have this issue.

I do understand how 301 redirections work and stay in the browser cache... but I don't understand what is setting this? And why it's happening to me?

For more context, I'm running 2 Storybooks at the same time, one referencing another one, in a monorepo but in 2 different packages with the cache being separated from each other (it should after check). @ndelangen according your answer, can this setup messes with an 301? (ref of context: #12108 (comment))

Thank you,

EDIT: I guess you prefer a reproduction repo' but I just started the project a few days ago and trying to build up things (even if familiar to Storybook). There is a few documentation to set it up locally, but don't loose your time if the stack with pnpm is too specific to you (https://github.com/sneko/dsfr-connect/tree/sb-issue)

[ndelangen]

You might have a serviceWorker still running on the same origin, maybe?

[sneko]

I went too fast on reading this (thought someone had issues with http-server too)! Sorry... all answers mentioning serve as the issue are right.

By default serve uses a cleanUrls=true which set a 301 on paths ending by .html. Unfortunately this is not configurable through the CLI (https://github.com/vercel/serve/blob/155b412b6cc3ddc912a7c969342cd0047332cfd2/source/types.ts#L58 and facebook/docusaurus#7991). So easier for me to switch to http-server to not face this in the futur.

Some threads about this: vercel/serve#404 vercel/serve#565

Thank you all,