Install-storybook NPM

Akeneo design system

This is my own thoughts about design system and totally open to debate.

UX team

The UX team creates the guideline with their own tool, deployed at here This is the source of truth for new shared components dev. The UX team is in charge to identify the needs for new components through time / features. When a new shared component has been identified, the UX team have to contact the dedicated squad to create a new jira task.

Dev team

Ideally each squad will have a dedicated front end dev, which mission is to enforce the usage of the shared library. This is to emphasis the fact that the shared lib must be now be use as a standard dependency and avoiding the creation of the same component multiple times.

Akeneo shared library

Everybody can push on the library (still not sure about that). Some frontend dev will be designated as referent, and one of their approval will be needed to merge the pr. This is to enforce the code quality and best practices, especially at the beginning of the repo life (and on the long term the ramp up of everyone ?).

Testing

The chosen testing lib is React Testing Lib (recommended by the React Core Team). CI on each pr. Snapshot testing is allowed but only for little chunk of code. I would like to try to use Cypress on the future, for E2E test and more (to poc).

Release cycle and tooling

ATM the Akeneo shared lib is on the CE repo and linked to no cycle release.

The lib will be a workspace and a dependency in the CE, and the lib will be publish on the npm registry. The lib will be a dependency for the EE and shared-catalogs. A tool is needed to help the dev in the case you need to create a new shared component on the EE or shared-catalogs, to watch and copy your file (or a local publish with yarn link, this is to poc). IMHO the shared lib must have its own cycle release and changelog. As Akeneo will grow this will give us more flexibility (new project, different stack SaaS, PaaS, legacy onPrem).