You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have made a few decisions about the structure of the project that may be causing people working with x-dash a little more friction than we may have realised so this issue is to collect those small gripes and propose solutions to help smooth them out.
Storybook
Storybook is intended (whether document or not) to run at the root of the component code that it is intended to load and display. This seems to mean the repository root (see examples a, b, c, and d) but I don't think this is required.
We decided to keep our storybook configuration and dependencies in a separate part of the repository tools/x-storybook. This works OK but we are having to work around a few limitations imposed by this decision and we cannot advise following the Storybook documentation to set up components.
To ensure Storybook works correctly we must declare our components as dependencies to link them in. This is because Storybook can only watch files which are descendants of the working directory (my understanding is that this is not a limitation of the tool itself but is a commonly applied rule).
I propose that it may be worth making storybook a top-level dependency of the project and moving the configuration to the top-level as well so that it matches other projects using Storybook and Storybook documentation itself.
Docs
This is a small suggestion should the proposed change to our Storybook setup happen...
Moving Storybook would leave the tools directory with only one item, x-docs. For consistency with other projects I think it would be good to also to move the x-docs folder to the top level as a www or website directory (see examples e, f, and g).
Move private packages
It is not obvious that our private packages x-rollup, x-babel-config, x-logo, and x-test-utils are private when looking at the directory structure. I think it could be made clear by keeping only public packages in the packages directory and moving the private packages into the (potentially vacated) tools directory.
Thoughts?
The text was updated successfully, but these errors were encountered:
We have made a few decisions about the structure of the project that may be causing people working with x-dash a little more friction than we may have realised so this issue is to collect those small gripes and propose solutions to help smooth them out.
Storybook
Storybook is intended (whether document or not) to run at the root of the component code that it is intended to load and display. This seems to mean the repository root (see examples a, b, c, and d) but I don't think this is required.
We decided to keep our storybook configuration and dependencies in a separate part of the repository
tools/x-storybook
. This works OK but we are having to work around a few limitations imposed by this decision and we cannot advise following the Storybook documentation to set up components.To ensure Storybook works correctly we must declare our components as dependencies to link them in. This is because Storybook can only watch files which are descendants of the working directory (my understanding is that this is not a limitation of the tool itself but is a commonly applied rule).
I propose that it may be worth making storybook a top-level dependency of the project and moving the configuration to the top-level as well so that it matches other projects using Storybook and Storybook documentation itself.
Docs
This is a small suggestion should the proposed change to our Storybook setup happen...
Moving Storybook would leave the
tools
directory with only one item,x-docs
. For consistency with other projects I think it would be good to also to move thex-docs
folder to the top level as awww
orwebsite
directory (see examples e, f, and g).Move private packages
It is not obvious that our private packages
x-rollup
,x-babel-config
,x-logo
, andx-test-utils
are private when looking at the directory structure. I think it could be made clear by keeping only public packages in thepackages
directory and moving the private packages into the (potentially vacated)tools
directory.Thoughts?
The text was updated successfully, but these errors were encountered: