Nota: Projeto corporativo — código-fonte privado. Descrito aqui apenas em termos de arquitetura e processo.
O problema
Vários times construindo telas parecidas sobre a mesma base de Ant Design, cada um resolvendo tabela, filtro e layout do seu jeito. O resultado é divergência visual, retrabalho e acessibilidade tratada como item de final de sprint — quando é tratada.
As decisões
- 01
Componentes de alto nível, não wrappers
Em vez de reembalar botão e input, a biblioteca entrega as peças que realmente se repetem: tabela de dados, barra de filtros e ações, e o shell da aplicação.
- 02
Acessibilidade verificada em CI
Suíte dedicada com Vitest, Testing Library e jest-axe, mais o addon de a11y no Storybook e um checklist versionado. Regressão de acessibilidade quebra o build.
- 03
Documentação que decide, não só descreve
Além do Storybook, um guia de decisão (quando usar, quando não usar, do/don't, composição, espaçamento, microcopy) e exemplos por domínio. A dúvida do consumidor costuma ser 'qual componente', não 'quais props'.
- 04
Distribuição como pacote real
Build dual ESM/CJS com tipos via tsup, peer dependencies para não duplicar React ou antd, e versionamento semântico automatizado com Changesets.
O resultado
- Pacote instalável, versionado e com changelog gerado a cada release.
- Acessibilidade como porta de entrada automatizada, não revisão manual.
- Menos tempo por tela nova nos times consumidores.