Add ability to hide dev-only stories from the production storybook

[tay1orjones]

In some instances, it's helpful to add a story to the storybook for development and testing purposes. These stories are not helpful to the consumer though, and would promote confusion if included in the production site/build.

For these cases, it would be nice if there was a way to add these stories, but have them in a special section that is not included in the production build.

#12971 (comment)

A few potential approaches

Use a environment flag to turn on/off dev mode

• This dev mode would need to be applied in the netlify deploy preview environment. It is currently considered a 'production' environment, but we would want to show the dev stories for testing.
• Ideally our CI and e2e tests would run against all these stories as well. This could be a good way to increase our visual snapshot coverage without introducing a bunch of stories that are only there for snapshotting purposes (e.g. input variants - readonly, disabled, etc.)

Option A:

Author stories in *.dev.stories.js files, and exclude these from the build in .storybook/main.js

• Benefits: clear separation from production stories
• Cons: does not live alongside other stories, more difficult to copy paste and maintain as component APIs change

Option B:

Author stories in the same file as production stories, but add a flag/prefix to their names, e.g. DEV_ReadOnlyInputExamples

• We could use this prefix to exclude these stories from the build in via the excludeStories option
• Excluding specific story exports from static builds storybookjs/storybook#15134
• Maybe something like excludeStories: process.env.DEV_MODE ? /.*DEV$/ : [], in each story file
• Benefits: dev stories live alongside production ones, maintenance is easier
• Cons: less clear separation, but would be easy to find/identify dev stories with an all-caps DEV_ (or similar) prefix

I think ultimately the best approach right now could be to add the environment flag, and use option B

Concerns

• This could become a wasteland dumping ground of unhelpful stories that are only used once for bug-repo/resovle.
  • To address, could we define some parameters around why/when we add a dev-only story vs not?
• Visually snapshotting production and dev-only stories could quickly run up our snapshot count, exceeding the quota.
  • To address, could we provide a way for stories to be exempt from snapshotting to avoid running up our snapshot count?

Examples of stories that would be nice to have in a dev-only mode

• Read only input comparison story (from [DO NOT MERGE]: Read only rollup #12601), mainly for snapshot purposes
• ...

[tw15egan]

Adding to this, it would be nice to have dev-only stories that showcase the component in various states that could be run against Percy instead of running multiple snapshots against one component. For example,

Dropdown has a story for default, inline, inline with layer, and skeleton. It would be nice to dump all of these into one story and expand upon this by having variants in invalid and warning states, one that is opened, hovered, focused, etc., and only snapshot this file. That way, we can capture more style bugs before they happen.

I noticed this when making changes to the status-success token and anticipated Percy catching it. However, we only showcase the error notification, so Percy did not catch anything. It would be helpful to showcase each Notification variant in a story only seen in dev / Percy.

[sstrubberg]

Due to some recent work @francinelucca had done to our Storybook the need for dev-only stories has diminished. Will revisit in the future if needed.

[tay1orjones]

Since this was opened, a separate idea was delivered that meets a lot of the use cases outlined here. We can now pass control/args configuration parameters on playground stories to the visitStory() function in e2e tests. It takes some of the wind out of the sails of this idea, and may outright eliminate it.

Are there other use cases where having dev-only stories would be helpful?