Engineering Contribution
Once you have the design assets or your engineering-only request is validated, you're ready to start the engineering phase. The contributor should develop the component in GitHub and request a review from a committee member.
- Talk to your designer: Ensure the design is approved by MDS before starting a PR.
- Implement: Think about the API and functionality, and build the component with the related story.
- Test: Check if the story covers everything.
- Pull request: Submit a draft PR, mark it as "Ready for review" once tests pass, and request a review.
- Merge: Merge the pull request in GitHub.
Engineering checklist
Follow this checklist to ensure standardized quality for all MDS components.
- The component is implemented strictly according to the approved design. The component API does not allow extra variants or behavior that is not documented.
- The implemented component is modular and follows the separation of concerns principle. Every component has a clear purpose and should contain logic, styles, and types regarding it.
- The component considers accessibility from the start (WCAG 2.2 Level AA compliance). While full accessibility implementation can be completed in a future iteration, initial design and technical decisions must ensure accessibility can be added without significant refactoring.
- External dependencies are minimized to keep the bundle size small and maintain independence. Avoid adding third-party libraries (e.g., lodash, fp-ts, drag-and-drop utilities) and internal dependencies (e.g., @mews/framework) unless absolutely necessary.
- Complex functions and accessibility features are covered with tests.
- All fundamental values (spacings, colors, elevations, …) are connected to design tokens.
- There's a Storybook story defined for every component following CSF 3.0 format (writing guide). At minimum, a Playground story presents the component in isolation with all relevant controls available for interaction. Additional example stories can be added as needed, avoiding overlapping or cases easily demonstrated via controls. The component API should be documented through JSDoc comments in the TypeScript interface, the story itself must have no accessibility violations (verified using the A11y add-on), and controls must be robust and cannot break the Storybook UI.
- Technical documentation is written and published on mews.design.
- Modified components maintain backward compatibility or document breaking changes in the changelog. Changes are tested across all known product implementations to verify no regressions.