-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Refactored storybook component library #1266
Changes from all commits
3fdd1a1
08f3f83
294923b
abac2be
b7a9110
59d4cc2
436767d
0be8829
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,7 +3,7 @@ build | |
coverage | ||
node_modules | ||
**/example/** | ||
**/demo/** | ||
app/**/demo/** | ||
docs/public | ||
|
||
*.bundle.js | ||
|
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we export
Button
directory from the package? Importing from a sub-path doesn't seem kosher to me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tmeasday @ndelangen my understanding (possibly wrong) was that
demo
is just one type of component, and that we are going to move all the storybook components into here. If that's the case, I think importing from a sub-path makes sense.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that it's generally not a great idea to ask users to require from files inside your package. It's obviously not universal not to do it (e.g.
react-test-renderer/shallow
), but I think you'll notice most packages are moving away from it. The main reason is it is brittle:You lose the flexibility to re-arrange how your files are organised in your package--certain files have to remain no matter what.
You expose details of your build process (cf
/dist/
being in the path). This is a bit ugly and restrictive again--e.g. what happens in the future when we don't need babel any more anddist
is redundant? Or iflerna
has some great new technique that favours a different naming of output files?Also, tooling understands the module entry point (
package.json#main
), whereas other entry points are just not going to be picked up. This also means new devs don't have any way to know which of our files users may be importing, exacerbating fix sidebar - content float issue #1.It doesn't seem that hard to export everything from a common entry file to me.
OTOH, Storybook already asks users to import from paths a bit so if you want to do it, fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tmeasday I'll think about it. Exposing all components as 1 module would mean we should allow tree shaking, because otherwise there's the potential for package bloat.
In fact maybe we should open an issue for exposing the es-modules code for all packages https://github.com/rollup/rollup/wiki/pkg.module