Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI option for start-storybook to not open the browser #6201

Closed
simbo opened this issue Mar 20, 2019 · 39 comments
Closed

CLI option for start-storybook to not open the browser #6201

simbo opened this issue Mar 20, 2019 · 39 comments

Comments

@simbo
Copy link

simbo commented Mar 20, 2019

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? ;)

@shilman
Copy link
Member

shilman commented Mar 20, 2019

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

Are you proposing:

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

@simbo
Copy link
Author

simbo commented Mar 20, 2019

It seems so... :)

@shilman
Copy link
Member

shilman commented Mar 21, 2019

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.

@shilman shilman added this to the 6.0.x milestone Mar 21, 2019
@bebbi
Copy link

bebbi commented Mar 21, 2019

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.

@Hypnosphi
Copy link
Member

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

@Hypnosphi
Copy link
Member

favor Chrome over default browsers

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

@backbone87
Copy link
Contributor

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

@stale
Copy link

stale bot commented Apr 12, 2019

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!

@stale stale bot added the inactive label Apr 12, 2019
@shilman
Copy link
Member

shilman commented Apr 12, 2019

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

@stale stale bot removed the inactive label Apr 12, 2019
@Hypnosphi
Copy link
Member

Hypnosphi commented Apr 13, 2019

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

@backbone87
Copy link
Contributor

backbone87 commented Apr 13, 2019

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

@kutenai
Copy link

kutenai commented Apr 21, 2019

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.

@shilman
Copy link
Member

shilman commented Apr 21, 2019

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

@kutenai
Copy link

kutenai commented Apr 21, 2019

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.

@jessepinho
Copy link

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

@Hypnosphi
Copy link
Member

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

@shilman
Copy link
Member

shilman commented May 5, 2019

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

@stale stale bot added the inactive label May 26, 2019
@shilman shilman removed the inactive label May 26, 2019
@stale stale bot added the inactive label Jun 16, 2019
@shilman shilman removed the inactive label Jun 16, 2019
@SeedyROM
Copy link

SeedyROM commented Jun 25, 2019

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.

@Hypnosphi
Copy link
Member

Hypnosphi commented Oct 9, 2019

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

@vandijkstef
Copy link

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.

haszari added a commit to woocommerce/woocommerce-blocks that referenced this issue Jan 24, 2020
haszari added a commit to woocommerce/woocommerce-blocks that referenced this issue Jan 27, 2020
haszari added a commit to woocommerce/woocommerce-blocks that referenced this issue Jan 30, 2020
haszari added a commit to woocommerce/woocommerce-blocks that referenced this issue Jan 30, 2020
haszari added a commit to woocommerce/woocommerce-blocks that referenced this issue Jan 30, 2020
* install & configure storybook (via magic npx script)

* fix indentation in storybook generated files

* eslint ignore generated storybook files (for now at least)

* unhide storybook folder, consistent with Gutenberg project

* demo story for one of our components (with no css/styles)

* hack in scss webpack config & add story for button:
- fixes scss imports breaking storybook build
- note scss / styling doesn't work yet
+ organise our component stories into folder

* git ignore storybook-static build folder

* pin dependencies for storybook

* piggy-back off main webpack config for storybook module.rules (for scss)

* use gutenberg (wp-components) styles in storybook

* use system font for storybook, consistent with wp-admin/gberg and reasonable default for components in front end

* add --ci flag to prevent storybook opening new browser tab…
- see also storybookjs/storybook#6201

* rename default stories to Default (following Gutenberg pattern)

* add story for ErrorPlaceholder

* failing ProductPreview story (committing to PR as an example for discussion)

* storybook for components/icons

* fix aliased dependencies in components for storybook:
append our webpack aliases to storybook webpack config

* basic story for PriceSlider (looks right but interaction broken)

* fix PriceSlider user interaction:
- PriceSlider expects client to handle onChange and pass in new min/max

* add comment about priceslider max/min (todoish)

* remove default stories from storybook scaffolding

* organise stories by module (aka folder in codebase)

* package-lock update after rebase

* remove unnecessary ignores (default stories are gone)

* delete experimental/risky/broken stories:
- icons components are changing in #1644
- we need to refactor/do more work to get ProductPreview working (settings globals)

* remove unnecessary import

* clarify PriceSlider component intended usage comment in story

* remove redundant wrapper divs from stories

* add common storybook addons (used by Gutenberg storybook)

* rebuild package.lock after rebase

* remove unnecessary wrapper div

* package fixes after rebase

* add configuration for storybook source loader

* add decorators for a11y and knobs plugins

* remove unnecessary react import & import useState from WP

Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
anito pushed a commit to anito/woocommerce-gutenberg-blocks that referenced this issue Feb 20, 2020
* install & configure storybook (via magic npx script)

* fix indentation in storybook generated files

* eslint ignore generated storybook files (for now at least)

* unhide storybook folder, consistent with Gutenberg project

* demo story for one of our components (with no css/styles)

* hack in scss webpack config & add story for button:
- fixes scss imports breaking storybook build
- note scss / styling doesn't work yet
+ organise our component stories into folder

* git ignore storybook-static build folder

* pin dependencies for storybook

* piggy-back off main webpack config for storybook module.rules (for scss)

* use gutenberg (wp-components) styles in storybook

* use system font for storybook, consistent with wp-admin/gberg and reasonable default for components in front end

* add --ci flag to prevent storybook opening new browser tab…
- see also storybookjs/storybook#6201

* rename default stories to Default (following Gutenberg pattern)

* add story for ErrorPlaceholder

* failing ProductPreview story (committing to PR as an example for discussion)

* storybook for components/icons

* fix aliased dependencies in components for storybook:
append our webpack aliases to storybook webpack config

* basic story for PriceSlider (looks right but interaction broken)

* fix PriceSlider user interaction:
- PriceSlider expects client to handle onChange and pass in new min/max

* add comment about priceslider max/min (todoish)

* remove default stories from storybook scaffolding

* organise stories by module (aka folder in codebase)

* package-lock update after rebase

* remove unnecessary ignores (default stories are gone)

* delete experimental/risky/broken stories:
- icons components are changing in #1644
- we need to refactor/do more work to get ProductPreview working (settings globals)

* remove unnecessary import

* clarify PriceSlider component intended usage comment in story

* remove redundant wrapper divs from stories

* add common storybook addons (used by Gutenberg storybook)

* rebuild package.lock after rebase

* remove unnecessary wrapper div

* package fixes after rebase

* add configuration for storybook source loader

* add decorators for a11y and knobs plugins

* remove unnecessary react import & import useState from WP

Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
@shilman shilman modified the milestones: 6.0.0, 6.0 breaking changes Mar 10, 2020
@shilman
Copy link
Member

shilman commented Jun 12, 2020

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

@cloud-walker
Copy link

Where can we see these improvements?

@shilman
Copy link
Member

shilman commented Jun 12, 2020

Available in 6.0-beta. #10329

@shilman shilman removed this from the 6.0 breaking milestone Jun 24, 2020
@MickL
Copy link

MickL commented Feb 2, 2021

I am not sure how this is related to continuous integration. In fact I am developing and it is annoying that storybook opens the browser on start. I am not doing ci so imo the naming is not correct. I would like to have a --open false option, too. Or even go for not open storybook by default (by comparison Angular CLI does not open by default, too) and then make the option --open true available.

@ghost
Copy link

ghost commented Mar 30, 2021

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

I landed here trying to stop the browser window from opening. If it could detect an existing open tab and reuse it I think 99% of people would be fine with that. But the concern with this issue (which has 47 upvotes at current) is that they simply don't want to have the browser window open and --ci is a misnomer.

@100terres
Copy link

100terres commented Apr 1, 2021

Hi everyone! I've take a look at the code of the library used to open the browser (beter-opn) and I've found these lines

https://github.com/ExiaSR/better-opn/blob/37065aa27fa1e5ad8c9f78a993d22b8ec3d9db23/src/index.js#L115-L117

case Actions.NONE:
  // Special case: BROWSER="none" will prevent opening completely.
  return false;

I've tried to add the environment variable BROWSER=none to my script and it seems to be working as expected!

Here's what I have in my package.json in the scripts section. Using the latest version of storybook.

"storybook": "BROWSER=none start-storybook",

A simple mention of the environment variable in the documentation could do the job. No code would need to be changed for it to work 🎉 🙂

cc @backbone87 @shilman

@shilman
Copy link
Member

shilman commented Apr 2, 2021

cc @jonniebigodes ☝️

@shilman
Copy link
Member

shilman commented Aug 2, 2021

Proposal: create a --open flag (which is true by default so this wouldn't be a breaking change) and then --no-open will set it to false. If open is false, then we simply don't call better-opn. Should be a small change! 💪

@shilman
Copy link
Member

shilman commented Aug 3, 2021

Yee-haw!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.4.0-alpha.23 containing PR #15739 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.

@shilman shilman closed this as completed Aug 3, 2021
@mattkenefick
Copy link

mattkenefick commented Feb 10, 2022

--no-open should really be the default :(

Opening an entire browser window by default is heavily opinionated and obtrusive.

@PumpkinPieGiraffe
Copy link

PumpkinPieGiraffe commented Jan 10, 2024

Yeah can we please make --no-open the default

Focusing the browser and opening a new tab when Storybook is ready is disorienting and really annoying

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests