Core: iframe.html no longer built with --preview-url

[sarahbethfederman]

Describe the bug
Since upgrading to 6.2.7 from 6.1.21, we're no longer seeing an iframe.html generated, and it seems the --preview-url flag has been removed from the CLI? I didn't see any release notes about this, and it's causing our CDN deploy to break.
Our build script looks like this

STORYBOOK_BASE_URL=$STORYBOOK_BASE_URL yarn build:storybook:docs --preview-url="${STORYBOOK_BASE_URL}iframe.html"

Screenshots
Before:

After:

Code snippets
If applicable, add code samples to help explain your problem.

System
Please paste the results of npx sb@next info here.

Additional context
Add any other context about the problem here.

┆Issue is synchronized with this Asana task by Unito

[shilman]

Argh, that looks like a fairly serious regression caused the by the webpack4/5 refactor. Looking into it now.

[shilman]

Hi @sarahbethfederman can you tell me more about your setup? I tried reproducing the problem in our monorepo (examples/standalone-preview) and everything is behaving as I would expect.

When you run build-storybook with --preview-url I wouldn't expect any iframe.html to be generated, and I'm not seeing one. Was there an iframe.html generated in 6.1.x?

[sarahbethfederman]

The situation we have is described here #3699 (comment)
There was previously an iframe.html generated and we were using the --preview-url to point it to the correct CDN url instead of /iframe.html

[shilman]

Ok, I've confirmed that iframe.html was generated in 6.1.x and is no longer generated in 6.2.x. My impression is that this is actually a bugfix that ended up being a breaking change in your case, is that correct? It shouldn't be hard to restore the old behavior, but I don't really understand why it's needed. Can you clarify a bit? I didn't understand #3699 (comment)

[sarahbethfederman]

By default our router/CDN setup only fetches the index.html, so all static assets need to refer to an absolute path with the ugly url that's generated in our deployment pipeline. The publicPath webpack setting works for this with mostly, with the exception of the iframe.html which doesn't respect this setting. By default the <iframe> src in the index.html refers to /iframe.html and the only way to point it to our <ugly_url>/iframe.html without going through a whole bunch of router settings I don't have access to was to use the --preview-url flag. If #3699 were fixed it would eliminate the need for this.

I'm not sure if it was a "bugfix" because the actual use case for --preview-url didn't seem to be documented :)

[shilman]

Ok thanks for explaining. I'll see if i can restore the old behavior for now (or maybe fix the other bug?!), and there's a good chance we'll be revisiting the preview url feature in the coming months

[sarahbethfederman]

Awesome, thanks!!

[shilman]

@sarahbethfederman I don't think the build points to /iframe.html anymore, but instead to iframe.html, which should solve the real issue here. Can you give that a try on your end and let me know if it's doing the right thing for you? If not, would it be possible to create a simple repro illustrating the problem? Thank you! 🙏

Side note: I've taken a look at the 6.1 => 6.2 changes and it would be easy to roll this back. However, I'd like to solve the real problem here if possible.

[sarahbethfederman]

Yeah unfortunately going to iframe.html instead of /iframe.html is still an issue since it needs the absolute path (similar to delivering images via CDN). I can't really set up a repro without creating a new pipeline atm. I guess I'm just unclear as to why the publicPath would effect everything but the iframe location. Was that a conscious design choice, or is it something that can be changed?

[manuelpuyol]

@shilman I'm having the same issue with v6.2 :(

In primer_view_components we demo our components using a Rails app that servers the static Storybook files. We place them at public/view-components/stories so it is accessible at localhost:4000/view-components/stories.

Initially, we built the static files with build-storybook -o public/view-components/stories. But we had an issue that when accessing localhost:4000/view-components/stories requested all JS files correctly, but tried to fetch iframe.html from localhost:4000/view-components/iframe.html, which did not exist, instead of localhost:4000/view-components/stories/iframe.html.

The only way to fix that was adding a trailing / to the URL: localhost:4000/view-components/stories/ fetched the correct iframe.html path. Digging more, we discovered --preview-url=/view-components/stories/iframe.html, which forced iframe.html to always be fetched correctly, even without the trailing /.

That was all in v6.1, but now in v6.2 our storybook reverted to fetch the incorrect iframe.html and will only work with a trailing /.

[KarlBao]

Same problem. I'd like to deploy the storybook with subpath. So I change the config referenced to this answer.
However, the iframe.html is not generated when I set --preview-url option in the command.

[shilman]

Hurrah!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.3.0-alpha.45 containing PR #15030 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.

[votemike]

@shilman I can confirm that your fix fixes the problem which I believe was the problem the OP had.
However, it seems like a lot of people are using --preview-url to allow storybook to be served from a sub-directory as suggested here: #1291 (comment)
Perhaps if there was some documentation on the correct way to serve storybook from a subdirectory and some more information on what --preview-url should be used for, there would not be this confusion and the need for cli options such as --force-build-preview