Background/Goal
- At DST's 2022-10-03 Task Refinement, while discussing T317792 we surfaced that https://doc.wikimedia.org/codex/main/ may be confusing to users because VitePress often forces its own styles, producing an overall result that is halfway-Codex and halfway-VitePress. We are using Codex components in the demos, of course, but would like to incorporate more tokens (T305411) and accessibility. In its current state, this means we will have to override a lot of VitePress styles in order to use Codex, which means a lot of extra work.
- This spike's goal is to reconsider our implementation of the Codex docs site given these limitations and lessons learned, and better understand the benefits/risks of changes needed to the current implementation, versus initiating a new implementation that may enable us to "drink our own champagne" more easily.
- This is NOT a blocker to T317792.
User stories
- As a Codex consumer/contributor, I want to see that the Design Systems team is using Codex wherever possible, including their own docs site, so that I can have confidence that they trust and use their own product.
- As a DST team member, I want to understand the pros/cons (technical complexity, risks, etc) of sticking with our current implementation versus rebuilding the docs site (or something in-between), so that I can make an informed decision on prioritization.
Acceptance criteria
- Write-up of pros, cons, knowns, and unknowns (either as a comment in this task or elsewhere) of how we might use Codex more consistently in our own docs site...
- while staying with the current VitePress implementation
- in a new implementation (or something in-between)
Open questions
- Should we reconsider Storybook? It's more lightweight than VitePress, but it was not ready for Vue 3 we originally tried to use Storybook (~1.5 years ago).