Storybook: CLI option for start-storybook to not open the browser

Created on 20 Mar 2019  ·  31Comments  ·  Source: storybookjs/storybook

Is your feature request related to a problem? Please describe.
I restart start-storybook from time to time for different reasons from changed config to working on other things. Nevertheless, I do not close my storybook browser tab. And as start-storybook opens a new browser tab every time it starts, my tab bar gets filled up with multiple storybook tabs between other tabs. It's annoying and leads to confusion and tab cleanup time...

I also noticed my colleagues doing the same things resulting in the same problems...
And I was a bit surprised, that I couldn't find an option to not open the browser...

I know, there is --ci to skip interactive prompts and not open the browser, but it also skips interactive prompts. Although I didn't see any interactive prompts yet, using ci mode for daily usage just doesn't feel right...

Describe the solution you'd like

start-server --no-open should build and serve as usual but not open the browser window.

Describe alternatives you've considered

Opening the browser with start-storybook should be disabled by default and can be enabled by using --open.

Webpack supports the --open/ --no-open flags which are also mirrored by other CLIs which use webpack internally.
angular cli and vue cli offer the same flags and - like webpack-dev-server - don't open the browser by default.

From my personal perspective, opening the browser by default is an opinionated bad-practice.
But I know, there are different opinions about this out there... :)

Are you able to assist bring the feature to reality?
Yes, I could dig into this and make a PR.

Additional context
Anybody want a screenshot of my browser tab bar filled with storybook tabs? ;)

BREAKING CHANGE cli feature request todo

Most helpful comment

personally i would prefer --no-open to be the default

All 31 comments

Hi @simbo. AFAIK the --ci option does exactly that.

Are you proposing:

  • renaming or aliasing it to --no-open
  • making it true by default?

It seems so... :)

Alias. I'm fine with adding a --no-open alias to --ci to make the feature more discoverable. We could also make it a separate flag if at some point there are more things that we don't want to do when we're in CI aside from just not opening the browser.

Default value. As for changing the default to --no-open, I'm not opposed to it, though it would be a breaking change so we'd want to do it in 6.0. I'm posting this issue in the #maintenance Discord so hopefully we can get some consensus. If so, it's a trivial change but it will probably take awhile to release.

It may not be the same. I think CRA handles this in a graceful way and could be adopted. Key differences are:

  • target the tab that's already open instead of opening a new one every time.
  • set preferred browser or do not open -> .env file
  • favor Chrome over default browsers (e.g. for people that browse with a different browser than they develop, of which there seem many - Chrome is still a safer bet for the majority).

Relevant CRA documentation

For me, start-storybook opens a tab in a backgrounded window of a different browser everytime I restart it.

it also skips interactive prompts

One example of such prompt is about running Storybook an alternative port when the requested one is busy. That can be quite useful sometimes. So I think, --no-open shouldn't be an alias for --ci. It should only disable the opening

favor Chrome over default browsers

Yeah, that's why I didn't copy that approach as-is

personally i would prefer --no-open to be the default

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!

Does anybody prefer the current behavior? If not, I think we can make the change

I do. Actually I'm kinda relying on it as an indication that storybook has finished building

maybe we just provide both cli flags: --open and --no-open and allow to configure this once storybook.config.js landed.

I would prefer a --no-open flag as well. Do everything that is currently default, just skip opening a new browser. I VERY often have an existing window open but must close and re-start the storybook process (due to configuration changes, etc), so I cannot rely on the auto-restart. In those cases, I just don't want a new browser.

@kutenai Can you just run with --ci? The discussion here is whether that behavior should be the default.

It appears to work fine for me. Maybe the option is just misleading, as it kind of implies that it does "more" than I want, but in practice, it seems to work fine.

FWIW, create-react-app lets you set a BROWSER env variable to choose which browser to open, or none to prevent any browser from opening. Could be worth looking into

The discussion here is whether that behavior should be the default.

You actually liked my comment that says that it should be a separate option

You actually liked my comment that says that it should be a separate option

Yeah I'm absolutely on board with making --no-open a separate option. I also think it should be the default and that's what I'm hoping to get consensus on for 6.0

The --no-open being default seems like a sane default to have, honestly opening a browser window by default seems like it's mostly for flash in a conference talk and does nothing but annoy developers who actually reload this command quite often.

For now:
I guess I'll use the --ci flag.

I would also like the default to be not to open the browser, and fwiw my first guess was that I could add BROWSER=none like cra -- so it might be worth adopting that method for consistency. I might not be the only one who would guess that before looking at docs.

My understanding of react-script's start behavior is that by default it opens a tab and if there is one already open, it re-uses that tab.

I love that behavior. If I've been working on a project through code changes and inevitable app/webpack crashes, I don't have to worry about bloating my windows with new tabs of the same app or flipping a flag to open a new tab.

We should also be careful of having two commands to run during normal dev workflows: start-storybook --open on the initial start and then start-storybook [--no-open] on subsequent commands. If tab re-use is possible, this is not a problem as my workflow would then just always be start-storybook --open.

I would prefer Storybook's default be to open a tab but am fine if y'all decide not to. I would love to see the tab re-use behavior come through though.

@JonKrone Unfortunately it only reuses the existing tab on HMR as far as I know. If I re-run the CLI it always opens a new tab for me (on Chrome/OSX at least).

I can not get --ci to work. Still opens a new tab in chrome each time I start it. I'm on 5.2.1 with vue.

@SebbeJohansson can you double check? working for me

@shilman I just did with a completely new setup just to make sure.
\My-Storybook>npm run storybook --ci
Results in a new tab in my primary browser.

@SebbeJohansson when using npm run, you have to prepend -- to all the arguments that you want to pass to the underlying command:

npm run storybook -- --ci

https://docs.npmjs.com/cli/run-script

As long as restarting isn't properly targeting the same browser window/tab (and/or reloading it), opening a new window by default is just frustrating for me. I think this is an anti-pattern a lot of packages are using to be fancy or something. We're all capable of opening a browser by the time we know how to handle npm.

After building it shows a nice box with 2 url's I can ctrl-click on, and most of us probably use start-storybook while developing and restarting a lot.

TLDR: Upvoting --ci as default and opening in browser by flag

restarting a lot

Why do you need that? start-storybook should pick your changes. If it doesn't, it sounds like an issue by itself.

We're all capable of opening a browser

Of course you know how to open the browser, the problem is that you don't know when. In large projects, first build may take quite a while, and just sitting and waiting for the box in the console may be not an option

Why do you need that? start-storybook should pick your changes. If it doesn't, it sounds like an issue by itself.

It should, and does on most changes, but not all changes. I'm currently setting up a new Storybook and fiddling around with it, so yes I ended up with 10 tabs in a few minutes.

Of course you know _how_ to open the browser, the problem is that you don't know _when_. In large projects, first build may take quite a while, and just sitting and waiting for the box in the console may be not an option

I could still open the browser, it'll just tell me 'Connection refused'. I think it's more annoying that after a minute or 2 suddenly a browser is popping up while I'm doing something else.
There could be a comment in the box there is a --automagically-open-in-browser (working title) flag you can enable.

Note I'm seeing this pattern across the industry, and where used, issues, & (stackoverflow) questions pop up everywhere how to disable it. I heavily dislike the pattern as a default, especially since targeting the same tab isn't solid technology. Meanwhile, once opened, a disconnect to the 'server' could start polling and reload once it comes back up again.

Proposal: Instead of doing all this, can we just add a message to CLI output notifying the user of --ci option if they don't want it to open the browser? The current behavior is much better thanks to @yannbf 's improvements

Where can we see these improvements?

Was this page helpful?
0 / 5 - 0 ratings