Como contribuir

Configuração

Faça uma mudança pequena no lugar certo e envie como pull request.

Antes de começar

Abra uma issue primeiro, ou comente em uma que já existe. Diga o que você quer mudar e por quê.
Espere uma resposta, para não construir algo que não vai ser aceito.
Termine a Configuração inicial para conseguir compilar e executar o HolyArrs.

Perguntas vão para o Discord. Ideias vão para o r/HolyArrs. As issues são para bugs e para o roadmap.

Envie seu primeiro pull request

Encontre o módulo onde sua mudança se encaixa. Os nomes em Módulos são iguais aos nomes das pastas, então um alerta errado no Discord é uma mudança em alerts.
Faça a mudança em app/backend/internal/<module>/ e app/frontend/src/lib/<module>/. Fique em uma correção ou um recurso só.
Compile o app web, depois o programa, e teste a mudança no navegador. Veja Configuração inicial.
Execute as verificações de Testes.

Você não deve ver nenhuma falha.
Se você mudou uma página, execute o projeto de ponta a ponta dela, por exemplo npm --prefix app/frontend run e2e -- --project=movies.
Abra o pull request. Coloque o link da issue, diga o que mudou e como você testou, e adicione ou atualize os testes da mudança.
No seu primeiro pull request, um bot pede para você assinar o acordo de licença de contribuidor. Responda com a frase que ele pede.

Opções

Para onde vai cada mudança

Mudança	Vá para
Uma rota nova	Módulos
Um módulo novo	Módulos. Abra uma issue primeiro
Um recurso retido	Configuração inicial
Uma versão	Lançar uma versão. Só para mantenedores

Como é um bom pull request

Escreva comentários que digam por que o código faz o que faz. Nada de números do roadmap, datas, nomes ou travessões nos comentários.
Não mexa nos textos do app, a não ser que a issue seja sobre os textos.
Mantenha como estão os caminhos de API, nomes de campos, chaves de configuração, nomes de tabelas e nomes de tarefas que já foram lançados. Adicione, nunca renomeie.

Se não funcionar

Sintoma. Uma verificação de estrutura falha. Causa. A mensagem diz qual é o arquivo e qual é a regra. Solução. Mova o código, ou passe dados simples a partir do módulo mais alto. Veja Módulos.

Sintoma. O app web parece antigo. Causa. O programa serve a compilação que ele embutiu. Solução. Compile o app web de novo antes do programa.

Sintoma. Os testes de ponta a ponta não iniciam. Causa. O navegador de teste não está instalado. Solução. Execute npx --prefix app/frontend playwright install chromium.

Para especialistas

Regras que um pull request precisa respeitar

Um módulo fala com outro módulo só pelo serviço dele (Go) ou pelo index.ts dele (web). Nunca pelo store nem pelos arquivos dele.
O SQL fica só nos arquivos store*.go de um módulo, sobre as tabelas do próprio módulo.
Uma parte web vai para lib/ui só quando 2 ou mais módulos usam essa parte.
Nada de pacotes util, common, shared ou helpers.
Toda chamada externa passa por core/outbound.

Os testes verificam essas regras, então um import errado faz a compilação falhar. A lista completa e os nomes das verificações estão em Módulos.

O que o CI executa

Tarefa	Executa
Web	`check`, `lint`, `test`, `build` e a suíte de ponta a ponta
Go	`go build`, `go vet` e `go test -timeout 60m ./...` em `amd64` e `arm64`, nativamente e sob emulação
Race	`go test -race ./...`
Contrato	A correspondência do `openapi.json`, as verificações de escopo em cada rota, a suíte dos Gerenciadores de downloads
Falha e escala	Execuções de falha, escrita lenta, serviço externo com problema e memória
Imagem	Uma imagem de desenvolvimento é compilada, inicia e informa sua versão

Os detalhes das execuções longas estão em Testes.

Relacionados

O HolyArrs é gratuito. Se ele poupou seu tempo, dê uma estrela no GitHub, patrocine o projeto ou me pague um café.