Funcionalidades

• ⚡️ NextJS - Desenvolvido com NextJS

• 🔮 Velite - Camada de conteúdo (MDX) da documentação do design system

• 🦾 Typescript - Desenvolvido com o poder do Typescript

• 💻 ShadCN - Framework UI para desenvolvimento dos componentes. Baseado no RadixUI

• 🎨 Tailwind - Framework CSS que utiliza classes utilitárias através do Atomic CSS - Tailwind para React Native

• 🐶 Husky - Padronização e controle de commits

• 🚀 Eslint + Prettier - Padronização do código e lint de errors

O desenvolvimento e a documentação do projeto requerem Node >= 18.18.0 (exigência do Next 15)

Recomenda-se o uso do Yarn para o gerenciamento dos pacotes

Requisitos

Componentes

Todos os componentes que serão utilizados pela lib, deverão ser criados obrigatoriamente no seguinte diretório e na seguinte nomenclatura (.src/components/Nome.tsx)

Tailwind

Utilizamos o Tailwind para criação da nossa UI. Ele se utiliza do classes utilitárias através do Atomic CSS. Os arquivos de configuração dos tokens estão dentro da pasta (.src/assets/css/tokens.css)

Assets

Aqui deverá conter todos os assets que deverão ser usados na utilização da lib. Você encontrará na seguinte pasta (.src/assets/)

Gitflow

Utilizamos o padrão de gitflow do mercado. Temos três branchs principais: production (produção), homolog (homologação) e development (desenvolvimento). Quando estiverem desenvolvendo uma nova feature, se utilizar da seguinte nomenclatura: feat/nome-da-feature. Após a finalização deve-se criar a PR e fazer o merge com development. Por regra, as PRs somente podem ser mergeados após o review e aceite de pelo menos um integrante da equipe.

Commits

Nos commits deverá ser utilizado a convenção dos Conventional Commits.

Husky

Ferramente utilizada para padronizar e controlar os commits que são feitos dentro do projeto. Quando for realizar o commit lembre-se de utilizar os commits semânticos e de não ter nenhum erro de lint em seu código, caso contrário o husky bloqueará seu commit até que você corrija esses erros e caso a mensagem no commit não seja semântica o husky também bloqueará seu commit.

ESLint/Prettier

Para padronizar nosso código utilizamos o Eslint e o Prettier dentro de nossos projetos. É importante caso use o Vscode de utilizar as extensões: esbenp.prettier-vscode, dbaeumer.vscode-eslint

Utilização

Configuração

Rode o comando para instalar todas as dependências do projeto

yarn install

Rode o comando para instalar o husky

yarn prepare

Rode o comando para dar permissão aos scripts do husky

chmod ug+x .husky/*

Desenvolvimento

Rode o comando para iniciar o ambiente de desenvolvimento

yarn dev

OBS: Basta acessar o http://localhost:3000/ para visualizar a aplicação em seu browser favorito

Build

Para fazer o processo de build

yarn build

Para rodar a aplicação em modo de produção

yarn start

Para lintar possíveis erros da aplicação

yarn lint

Releases (Changesets, 100% automático)

Este repositório usa Changesets para versionar e publicar os 3 pacotes (@medway-ui/core, @medway-ui/native, @medway-ui/notes-core) de forma independente. Nenhum comando manual é necessário — o changeset de cada PR é gerado automaticamente a partir dos commits que ela traz, então basta seguir a convenção de commit que o Husky/commitlint já exige:

• fix: ... → patch
• feat: ... → minor
• feat!: ... ou um rodapé BREAKING CHANGE: ... no commit → major

O CI decide qual pacote foi afetado pelo caminho dos arquivos que cada commit tocou (src/ → core, native/src/ → native, notes-core/src/ → notes-core) — não é preciso declarar isso à mão. PRs que não mudam nada publicável (docs, chore de CI, etc.) simplesmente não geram nenhum changeset.

O que acontece depois do merge de uma PR de feature

Ao mergear na main, o workflow .github/workflows/release.yml roda para cada um dos 3 pacotes. Ele olha os commits desde o último bump de version daquele pacote na main e, se algum deles tocou os arquivos do pacote, gera um changeset automaticamente (arquivo em .changeset/, native/.changeset/ ou notes-core/.changeset/) com o tipo de bump inferido da mensagem de commit. A partir daí:

• Se a versão do package.json já está no npm: aplica o bump de versão (changeset version), atualiza o CHANGELOG.md, commita isso numa branch própria do pacote (changeset-release/core, changeset-release/native ou changeset-release/notes-core) e abre (ou atualiza) uma PR "chore: version @medway-ui/" direto contra main.
• Se a versão do package.json ainda não está no npm (a PR de versão já foi mergeada): builda e publica o pacote no npm e cria a tag.

Depois de publicar, o workflow espera a versão aparecer no npm e comenta em cada PR incluída no release ("Esta alteração foi publicada em pacote@versão"), marcando o autor.

Ou seja, cada release passa por 2 PRs: a da mudança em si, e depois a de versão — ambas contra main, revisadas e aprovadas normalmente, sem nenhuma branch intermediária protegida e sem nenhuma exceção de bypass. Só main tem proteção de branch (exige PR antes de merge).

@medway-ui/notes-core é sempre processado antes de core e native (ambos o declaram como peerDependency).

Limitações conhecidas

• A PR de versão é aberta com o token de um GitHub App (RELEASE_APP_ID como variável e RELEASE_APP_PRIVATE_KEY como secret, ambos na org), e não com o GITHUB_TOKEN, que não dispara outros workflows. Por isso o check Build roda nela e pode ser obrigatório no ruleset.

Quando um dev ainda quer escrever o changelog à mão

Rodar yarn changeset (ou cd native && yarn changeset / cd notes-core && npm run changeset) continua funcionando — cria um arquivo de changeset manual que o CI simplesmente encontra pronto e não regenera. Use isso quando quiser controlar o texto do changelog com mais cuidado do que o resumo automático (que é só a lista de mensagens de commit).