Storybook for all AP Components

[dselman]

I've recently completed a spike on aggregating all the AP components into a single Storybook, and investigated how we might use various features: knobs, notes, docs, actions ...

The results are here: https://github.com/accordproject/web-components

I also took the opportunity to standardise the build for all components to use react-create-library which does a nice job of web packing the libraries and standardises how they are tested, linted etc.

The repo above shows the following features:

• using Lerna to build a monorepo that contains our various components, each of which has its own package.json and dependencies
• using a Storybook package to aggregate all the components into a single Storybook
• importing an external component (the Cicero-UI components) into the Storybook
• Building the Storybook as a static site and publishing it to GH pages using a GH Action. I had to do this as Netlify ran out of memory trying to Webpack the site.

Note that I could not get Cicero-UI to play nice with react-create-library due to some strange Webpack errors, hence it is referenced as an external package from npm. More investigation needed....

Possible Actions and Questions

1. Is this the way we want to go?
2. Can we get Cicero-UI to play nice with react-create-library?
3. When/how do we refresh the code?
4. Do we care about losing GH history for the files?
5. We will need to do more work on each Story to add more useful knobs and actions
6. Do we want to move away from Netlify for static sites in general? The GH Actions are fast and seem to work well.
7. When do we cut over and archive the old repos?
8. We need to test that publishing the npm packages from the new repo works

[irmerk]

1. Is this the way we want to go?
2. Can we get Cicero-UI to play nice with react-create-library?

I think as long as we can get Cicero-UI to work with react-create-library, this is the route to go. All of our components are related (cicero-ui, concerto-ui, markdown-editor, etc.), and I think we should have them housed in the same area to reflect that. It just adds more difficulty on the potential consumer/developer to have them spread out. The added benefit of the Storybook having everything together for development and demoing purposes is great.

3. When/how do we refresh the code?

If we do keep them separate, I would think on major releases we would refresh. A sort of LTS version.

4. Do we care about losing GH history for the files?

A little bit, but not enough to sway me.

5. We will need to do more work on each Story to add more useful knobs and actions

Agreed, but this is already much better than the current demos we have, so I don't see this as an issue.

6. Do we want to move away from Netlify for static sites in general? The GH Actions are fast and seem to work well.

Faster, free, and more consolidation under GitHub sounds great to me.

7. When do we cut over and archive the old repos?
8. We need to test that publishing the npm packages from the new repo works

I think along with your second point, we would cut over once we solve the Cicero-UI in react-create-library and npm publishing issues.

[DianaLease]

I agree with the above. IIRC, cicero-ui's configuration is not much different from markdown-editor's, so I think we should be able to get it to work with create-react-library if the markdown-editor worked.

That seems to be the only blocker to this change for me. Although I don't really understand what is meant by 3. When/how do we refresh the code?.

[jeromesimeon]

A few things from my end:

• I would like to consolidate to use one deployment platform if possible for all our projects (e.g., only netlify or only GitHub pages/actions). I wouldn't do this for just one project. If we can move everything to GitHub pages then great. (separate questions there e.g., it's really easy to deploy every commit individually or to deploy specific branches with netlify -- can we do the same with GitHub actions)
• If we move everything under a single lerna monorepo, we should come up with consistent naming for the underlying packages.
• I'm personally a little worried that this becomes a huge project for which underlying packages may have different lifecycles (e.g., Concerto independent from Cicero, Markdown Editor being independent from other AP dependencies). It also means that whenever we make changes to the underlying components, all the different demos have to be maintained with it -- this can of course be at once a drawback and a benefit

[DianaLease]

On @jeromesimeon 's third point, I think we'll definitely still be able to have separate lifecycles for different projects. Also, often we'll release markdown-editor, then update cicero-ui to use that new release, and possibly then also release cicero-ui. How would that workflow go in this new setup? I assume we would still release each package separately, correct?

[irmerk]

Finished with web-components