Como Contribuir

React é um dos primeiros projetos de código aberto do Facebook que está sendo desenvolvido muito ativamente, além de ser usado para entregar código para todos em facebook.com. Nós ainda estamos trabalhando para tornar esse projeto mais transparente e fácil possível, mas ainda não estamos lá. Esperamos que essa documentação torne esse processo de contribuição mais clara e responda algumas perguntas que você possa ter.

Código de Conduta

O Facebook adotou o Convênio do Contribuinte como seu Código de Conduta, e esperamos que os participantes do projeto o adotem. Por favor, leia o texto completo para que você possa entender quais ações serão ou não toleradas.

Desenvolvimento Aberto

Todo trabalho no React acontece diretamente no GitHub. Tanto membros do Core Team quanto contribuidores externos devem enviar pull requests que vão passar pelo mesmo processo de revisão.

Versionamento Semântico

O React segue o versionamento semântico. Lançamos versões de patch para correções críticas, versões secundárias (minor version) para novos recursos e versões principais (major version) para qualquer alteração de quebra. Quando fazemos alterações significativas, também introduzimos alguns avisos de descontinuidade em uma versão secundária para que nossos usuários tenham conhecimento sobre as próximas alterações e migrem seu código com antecedência. Saiba mais sobre nosso compromisso com a estabilidade e a migração incremental em nossa política de versão.

Toda mudança significativa é documentada na changelog.

Organização de Branches

Envie todas as alterações para a branch master. Não usamos ramificações separadas para desenvolvimento ou para os próximos lançamentos. Fazemos o possível para manter a master em boas condições, com testes passando todas as vezes.

O código que chega na master deve ser compatível com a versão estável mais recente. Pode conter recursos adicionais, mas nenhuma alteração de última hora. Deveríamos ser capazes de lançar uma nova versão secundária apartir da master a qualquer momento.

Feature Flags

Para manter o ramo da master em um estado liberável, as alterações de interrupção e os recursos experimentais devem ser colocados atrás de uma feature flag.

Feature flags são definidas em packages/shared/ReactFeatureFlags.js. Algums builds do React podem ativar conjuntos diferentes de features flags; por exemplo, o React Native build pode ser configurado de maneira diferente que o React DOM. Essas flags são encontradas em packages/shared/forks. Feature flags são digitados estaticamente pelo Flow, para que você possa executar o yarn flow para confirmar que atualizou todos os arquivos necessários.

O sistema de build do React removerá as branches de recursos desativados antes da publicação. Um trabalho de integração contínua é executado em todas as confirmações para verificar alterações no tamanho do pacote. Você pode usar a alteração de tamanho como um sinal de que o recurso foi bloqueado corretamente.

Bugs

Onde Encontrar Problemas Conhecidos

Nós estamos utilizando as GitHub Issues para nossas páginas públicas. Nós vamos ficar de olho e tentar manter claro quando estamos trabalhando internamente na correção de algum bug. Antes de preencher uma nova tarefa, verifique se o problema já existe.

Relatando novos problemas

A melhor maneira de corrigir o problema é fornecer um caso de teste reduzido. Este template no JSFiddle é um excelente ponto de partida.

Bugs de Segurança

O Facebook tem um programa de recompensas para a divulgação segura de bugs de segurança. Com isso em mente, não reporte esses problemas de forma pública. Percorra o processo descrito nessa página.

Como entrar em contato

Há também uma comunidade ativa de usuários do React na plataforma no Discord caso você precise de ajuda.

Propondo uma alteração

Se você pretende alterar a API pública ou fazer alterações não triviais na implementação, recomendamos abrir uma issue. Isso nos permite chegar a um acordo sobre sua proposta antes de colocar um esforço significativo nela.

Se você está apenas corrigindo um bug, não tem problema em enviar uma pull request diretamente, mas ainda sim recomendamos abrir uma issue com detalhes sobre o que você está corrigindo. Isso é útil caso não aceitemos essa correção específica, mas queremos acompanhar o problema.

Seu primeiro Pull Request

Trabalhando em seu primeiro Pull Request. Você pode aprender como desta série de vídeos gratuitos:

Como contribuir para um projeto de código aberto no GitHub

Para ajudar você a se familiarizar com o nosso processo de contribuição, temos uma lista de boas primeiras issues que contém erros que têm um escopo relativamente limitado. Este é um ótimo lugar para começar.

Se você decidir corrigir um bug, por favor, verifique o tópico do comentário caso alguém já esteja trabalhando em uma correção. Se ninguém estiver trabalhando no momento, por favor deixe um comentário dizendo que você pretende trabalhar nele para que outras pessoas não dupliquem sem querer seu esforço.

Se alguém assumir uma issue, mas não fizer o acompanhamento por mais de duas semanas, não há problema em você assumir, mas mesmo assim você ainda deve deixar um comentário.

Enviando um Pull Request

O Core Team está monitorando os pull requests. Analisaremos seu envio e fazermos o merge, solicitaremos alterações ou podemos fechá-la com uma explicação plausível. Para alterações de API, podemos precisar corrigir nossos usos internos no Facebook.com, o que pode causar algum atraso. Faremos o nosso melhor para fornecer atualizações e feedback durante todo o processo.

Antes de enviar o seu pull request, certifique-se de ter feito os seguintes passos:

Faça fork do repositório oficial and criou sua branch da master.
Execute yarn no repositório raíz.
Se você corrigiu um bug ou um código adicionado que deve ser testado, adicione testes!
Certifique-se de que a suíte de teste passe (yarn test). Dica: yarn test --watch TestName é útil no desenvolvimento.
Execute yarn test --prod para testar no ambiente de produção. Suporta as mesmas opções que yarn test.
Se você precisar de um depurador, execute yarn debug-test --watch TestName, abra chrome://inspecte aperte em “Inspecionar”.
Formate seu código com prettier (yarn prettier).
Certifique-se de que seus códigos foram verificados com linters (yarn lint). Dica: yarn linc verifica somente os arquivos alterados.
Rode o Flow para typechecks (yarn flow).
Se ainda não fez, preencha o CLA.

Licença de Acordo de Contribuidor (Contributor License Agreement - CLA)

Para aceitar seu pull request, precisamos que você envie um CLA. Você só precisa fazer isso uma vez, então se você fez isso para outro projeto de código aberto do Facebook, você está pronto para continuar. Se você estiver enviando um pull request pela primeira vez, nos informe que você concluiu o CLA e então podemos fazer uma verificação cruzada com seu GitHub

Preencha sua CLA aqui.

Pré-requisitos de Contribuição

Possuir o Node instalado na versão v8.0.0+ e Yarn na versão v1.2.0+.
Possuir o JDK instalado.
Você deve ter o gcc instalado ou está confortável em instalar um compilador, se necessário. Algumas de nossas dependências podem exigir uma etapa de compilação. No OS X, as Ferramentas de Linha de Comando do Xcode cobrirão isso. No Ubuntu, apt-get install build-essential instalará os pacotes requeridos. Comandos semelhantes devem funcionar em outras distribuições Linux. O Windows irá requerer alguns passos adicionais, veja as instruções de instalação do node-gyp para detalhes.
Você deve ser familiarizado com o Git.

Fluxo de Trabalho de Desenvolvimento

Depois de clonar o React, execute yarn para buscar suas dependências. Então, você pode executar vários comandos:

yarn lint verifica o estilo de código.
yarn linc funciona como o yarn lint, mas é mais rápido porque verifica apenas os arquivos que diferem na sua branch.
yarn test executa o conjunto de testes completo.
yarn test --watch executa um observador de testes interativo.
yarn test --prod executa testes no ambiente de produção.
yarn test <pattern> executa testes com nomes de arquivos correspondentes.
yarn debug-test é como yarn test mas com um depurador. Abra chrome://inspect e clique em “Inspecionar”.
yarn flow executa o typecheck do Flow .
yarn build cria uma pasta build com todos os pacotes.
yarn build react/index,react-dom/index --type=UMD cria compilações UMD somente com o React e ReactDOM.

Recomendamos executar o yarn test (ou suas variações acima) para garantir que você não introduza nenhuma regressão enquanto trabalha na sua mudança. No entanto, pode ser útil testar sua versão do React em um projeto real.

Primeiro, execute yarn build. Isto irá produzir pacotes pré-construídos na pasta build, bem como irá preparar pacotes npm dentro da pasta build/packages.

A maneira mais fácil de testar suas alterações é rodar yarn build react/index,react-dom/index --type=UMD e depois abrir fixtures/packaging/babel-standalone/dev.html. Este arquivo já usa o react.development.js a partir da pasta build para que ele possa pegar suas alterações.

Se você quiser experimentar as alterações no seu projeto React existente, poderá copiar build/node_modules/react/umd/react.development.js, build/node_modules/react-dom/umd/react-dom.development.js ou qualquer outro build em seu aplicativo e usá-los em vez da versão estável.

Se o seu projeto usa React from npm, você pode excluir react e react-dom em suas dependências e usar o yarn link para apontá-los para a pasta local build. Note que em vez de --type = UMD, você desejará passar --type = NODE ao criar. Você também precisará criar o pacote scheduler:

cd ~/path_to_your_react_clone/
yarn build react/index,react/jsx,react-dom/index,scheduler --type=NODE

cd build/node_modules/react
yarn link
cd build/node_modules/react-dom
yarn link

cd ~/path/to/your/project
yarn link react react-dom

Toda vez que você executar yarn build na pasta React, as versões atualizadas aparecerão no node_modules do seu projeto. Você pode então reconstruir seu projeto para testar suas alterações.

Se algum pacote ainda estiver faltando (por exemplo, talvez você use react-dom/server em seu projeto), você sempre poderá fazer uma compilação completa com yarn build. Observe que executar o yarn build sem opções leva muito tempo.

Ainda exigimos que seu pull request contenha testes de unidade para qualquer nova funcionalidade. Dessa forma, podemos garantir que não quebremos seu código no futuro.

Guia de Estilo

Usamos um formatador de código automático chamado Prettier. Execute o yarn prettier depois de fazer qualquer alteração no seu código.

Então, nosso linter irá capturar a maioria dos problemas que possam existir em seu código. Você pode verificar o status do seu estilo de código simplesmente executando yarn linc.

No entanto, ainda existem alguns estilos que o linter não consegue captar. Se você não tem certeza sobre alguma coisa, veja o Guia de Estilos do Airbnb para te direcionar no caminho certo.

Pedido de Comentários (Request for Comments - RFC)

Muitas alterações, incluindo correções de bugs e melhorias na documentação, podem ser implementadas e revisadas por meio do fluxo de trabalho normal de pull requests do GitHub.

Algumas mudanças, entretanto, são “substanciais” e pedimos que estas sejam submetidas a um pequeno processo de design e produzam um consenso entre o Core Team do React.

O processo “RFC” (pedido de comentários) destina-se a fornecer um caminho consistente e controlado para que novos recursos entrem no projeto. Você pode contribuir visitando o repositório rfcs.

Licença

Ao contribuir com o React, você concorda que suas contribuições serão licenciadas sob sua licença do MIT.

O que vem a seguir?

Leia a próxima seção para saber como a base de código é organizada.

Esta página é útil?Edite esta página