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

Add support for storybook webpack configs #8

Open
transitive-bullshit opened this issue Nov 5, 2018 · 1 comment
Open

Add support for storybook webpack configs #8

transitive-bullshit opened this issue Nov 5, 2018 · 1 comment

Comments

@transitive-bullshit
Copy link

Add docz webpack support for other loaders and custom webpack settings that storybook contains by default (eg, css). This also encompasses potentially supporting custom user webpack configs that users have already hooked into via standard storybook overrides.

Currently, we bundle the storybook stories in two separate passes:

  1. With storybook itself, where the results are used strictly to gather story metadata
  2. With docz as an entry in its webpack config so stories are available from docz client-side

This process isn't ideal, but the main feature we want to support is for standard storybook webpack config settings (as well as user-defined webpack/babel customizations) to "just work" with step 2 above.

Here are some options for solving for this support:

A) Augment the webpack config in step 2 to add as much storybook compatibility as possible with expected things like CSS support.

B) Do no extra work aside from documenting additional docz plugins like docz-plugin-css that can be enabled manually by the user to add compatibility.

C) Remove step 2 above and replace it with a wrapper around the iframe bundle that storybook generates in step 1. One advantage here is that it provides maximum compatibility with storybook and any possible existing webpack customizations the user may have made. A disadvantage is that it adds more complexity to this plugin in terms of managing the docz host page and storybook code which is now isolated within an iframe.

I think option C has the most promise in terms of meeting our zero-config "just works" goal, but it's also the most complicated by far.

Very open to thoughts / feedback on this issue in particular.

@transitive-bullshit transitive-bullshit added the enhancement New feature or request label Nov 5, 2018
@transitive-bullshit
Copy link
Author

As of #18 and #19, we're currently using a mixture of options A and B above.

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

No branches or pull requests

1 participant