addons frontend
blog-utils-0.25.0
Infraestrutura front-end e código para complementar o mozilla/addons-server.
Este código e seu site de produção associado estão incluídos no programa de recompensas de bugs de serviços e web da Mozilla. Se você encontrar uma vulnerabilidade de segurança, envie-a através do processo descrito no programa e nas páginas de perguntas frequentes. Mais detalhes técnicos sobre este aplicativo estão disponíveis na página Bug Bounty Onramp.
Por favor, envie todos os bugs relacionados à segurança através do Bugzilla usando o formulário de bug de segurança da web.
Nunca envie bugs relacionados à segurança por meio de um problema no Github ou por e-mail.
A maneira mais fácil de gerenciar versões de vários nós em desenvolvimento é usar nvm.
Se você estiver no Windows, certifique-se de seguir também as diretrizes do Windows.
yarn para instalar todas as dependênciasyarn amo:stage para iniciar um servidor local que se conecta a um servidor de teste hospedado Aqui estão alguns comandos que você pode executar:
| Comando | Descrição |
|---|---|
| fio amo:olympia | Inicie o servidor de desenvolvimento/proxy (por exemplo) usando dados de um ambiente de servidor de complementos local. |
| fio amo:dev | Inicie o servidor de desenvolvimento/proxy (por exemplo) usando dados do servidor de desenvolvimento (https://addons-dev.allizom.org/) |
| fio amo:dev-https | Igual ao amo:dev , mas com HTTPS, disponível em: https://example.com:3000/. Leia sobre como configurar este ambiente |
| fio amo:estágio | Inicie o servidor de desenvolvimento/proxy (por exemplo) usando dados do servidor de teste (https://addons.allizom.org/) |
| construção de fio | Crie o aplicativo. |
| construção de fio-ci | Execute os scripts npm build e bundlewatch . |
| relógio de feixe de fios | Execute bundlewatch para verificar os tamanhos dos pacotes AMO gerados. Construir o AMO é necessário primeiro. |
| fluxo de fio | Execute o fluxo. Por padrão, isso verifica erros e sai |
| fluxo do fio: verificar | Verifique explicitamente se há erros de fluxo e saia |
| fluxo de fio:dev | Verifique continuamente se há erros de fluxo |
| eslint de fio | Lint o JS |
| fio start-func-test-server | Inicie um contêiner Docker para testes funcionais |
| estilo de fiolint | Lint o SCSS |
| fiapos de fio | Execute todos os linters JS + SCSS |
| fio mais bonito | Execute Prettier para formatar automaticamente toda a base de código |
| fio mais bonito-dev | Execute [Pretty-Quick][] para comparar e formatar automaticamente os arquivos de origem modificados em relação ao branch master |
| fio mais bonito-ci | Execute o Prettier e falhe se algum código tiver sido alterado sem ser formatado |
| verificação de versão do fio | Verifique se você tem as dependências necessárias |
| teste de fio | Execute todos os testes (entra em jest no modo --watch ) |
| teste-depuração de fios | Execute todos os testes com saída completa do console e mensagens de erro completas (entra em jest no modo --watch ) |
| cobertura de teste de fio | Execute todos os testes e gere o relatório de cobertura de código (entra em jest no modo --watch ) |
| cobertura de teste de fio uma vez | Execute todos os testes, gere o relatório de cobertura de código e saia |
| teste de fio uma vez | Execute todos os testes, execute todos os linters JS + SCSS e saia |
| teste de fio-ci | Execute todas as verificações de integração contínua. Isso deve ser executado apenas em CI. |
Você pode entrar no modo de brincadeira interativo digitando yarn test ou yarn test-debug . Esta é a maneira mais fácil de desenvolver novos recursos.
Aqui estão algumas dicas:
yarn test ocultará a maioria das saídas do console e mensagens detalhadas de falha de teste, por isso é melhor quando você estiver executando um conjunto completo de testes. Ao trabalhar em um teste individual, você provavelmente desejará executar yarn test-debug .yarn test , você pode alternar para o editor de código e começar a adicionar arquivos de teste ou alterar o código existente. À medida que você salva cada arquivo, o jest executará apenas testes relacionados ao código alterado.a quando começou, o jest continuará executando o conjunto completo mesmo quando você alterar arquivos específicos. Digite o para voltar ao modo de executar apenas testes relacionados aos arquivos que você está alterando.p ou t para filtrar os testes por nome enquanto trabalha na correção de um conjunto de testes específico. Mais informações.Error watching file for changes: EMFILE no Mac OS, então brew install watchman pode consertar. Veja jestjs/jest#1767 Por padrão, yarn test executará apenas um subconjunto de testes relacionados ao código em que você está trabalhando.
Para executar explicitamente um subconjunto de testes, você pode digitar t ou p que são explicados no uso do jest watch.
Alternativamente, você pode iniciar o executor de teste com um arquivo específico ou expressão regular, como:
yarn test tests/unit/amo/components/TestAddon.js
Se você deseja executar todos os testes e sair, digite:
yarn test-once
Ao executar os testes, você verá um relatório de erros do Eslint no final da saída do teste:
yarn test
Se você quiser executar testes sem verificações do Eslint, defina uma variável de ambiente:
NO_ESLINT=1 yarn test
Há suporte limitado para usar o Flow para validar a intenção do nosso programa.
Ao executar testes, você verá um relatório de erros de fluxo no final da saída do teste:
yarn test
Se você quiser executar testes sem verificações de fluxo, defina uma variável de ambiente:
NO_FLOW=1 yarn test
Para verificar apenas problemas de fluxo durante o desenvolvimento enquanto você edita arquivos, execute:
yarn flow:dev
Se você é novo no trabalho com Flow, aqui estão algumas dicas:
Para adicionar cobertura de fluxo a um arquivo de origem, coloque um comentário /* @flow */ na parte superior. Quanto mais arquivos de origem você ativar no Flow, melhor.
Aqui está nosso manifesto Flow:
getAllAddons recebe argumentos de objeto, chame seu tipo de objeto GetAllAddonsParams . Exemplo: type GetAllAddonsParams = { |
categoryId : number ,
| } ;
function getAllAddons ( { categoryId } : GetAllAddonsParams = { } ) {
...
}{| key: ... |} ) quando possível. Às vezes, o operador spread aciona um erro como 'O tipo inexato é incompatível com o tipo exato', mas isso é um bug. Você pode usar a solução alternativa Exact<T> de src/amo/types/util se for necessário. Isso é um substituto funcional para $ Exact. // Imagine this is something like components/ConfirmButton/index.js
import { compose } from 'redux' ;
import * as React from 'react' ;
// This expresses externally used props, i.e. to validate how the app would use <ConfirmButton />
type Props = { |
prompt ?: string | null ,
| } ;
// This expresses internally used props, such as i18n which is injected by translate()
type InternalProps = { |
... Props ,
i18n : I18nType ,
| } ;
export class ConfirmButtonBase extends React . Component < InternalProps > {
render ( ) {
const prompt = this . props . prompt || this . props . i18n . gettext ( 'Confirm' ) ;
return < button > { prompt } < / button > ;
}
}
// This provides a type hint for the final component with its external props.
// The i18n prop is not in external props because it is injected by translate() for internal use only.
const ConfirmButton : React . ComponentType < Props > = compose ( translate ( ) ) (
ConfirmButtonBase ,
) ;
export default ConfirmButton ;Object ou any , mas sinta-se à vontade para usá-los se estiver gastando muito tempo declarando tipos que dependem de outros tipos que dependem de outros tipos, e assim por diante.$FlowFixMe para pular uma verificação de fluxo se encontrar um bug ou se acertar algo que esteja fazendo você bater a cabeça no teclado. Se for algo que você acha que não pode ser corrigido, use $FlowIgnore . Explique seu raciocínio no comentário e crie um link para um problema do GitHub, se possível.yarn flow type-at-pos ... para rastrear quais tipos estão sendo aplicados ao código. Consulte yarn flow -- --help type-at-pos para obter detalhes.Usamos o Prettier para formatar automaticamente nosso código JavaScript e interromper todos os debates contínuos sobre estilos.
Para ver um relatório de cobertura de código, digite:
yarn test-coverage-once
Isto imprimirá uma tabela de arquivos mostrando a porcentagem de cobertura de código. As linhas descobertas serão mostradas na coluna da direita, mas você pode abrir o relatório completo em um navegador:
open coverage/lcov-report/index.html
Um servidor proxy é fornecido para executar o aplicativo AMO com a API no mesmo host do frontend. Isso imita nossa configuração de produção.
Comece a desenvolver em uma API hospedada como esta:
yarn amo:dev
Isso configura o proxy para usar https://addons-dev.allizom.org para dados de API. Este comando é a forma mais comum de desenvolver novos recursos de frontend. Consulte a tabela de comandos acima para maneiras semelhantes de executar o servidor.
Para usar um servidor API local em execução no Docker, você pode usar o comando yarn amo . No entanto, isso não está funcionando atualmente. Consulte o problema-7196.
A autenticação funcionará quando iniciada a partir do addons-frontend e persistirá no addons-server, mas não funcionará ao efetuar login a partir de uma página do addons-server. Consulte mozilla/addons-server#4684 para obter mais informações sobre como corrigir isso.
Se você precisar substituir qualquer configuração ao executar yarn amo , yarn amo:dev ou yarn amo:stage , primeiro crie um arquivo de configuração local chamado exatamente assim:
touch config/local-development.js
Faça quaisquer alterações de configuração. Por exemplo:
module . exports = {
trackingEnabled : true ,
} ;Reinicie o servidor para ver o efeito.
Consulte a documentação da ordem de carregamento do arquivo de configuração para saber mais sobre como a configuração é aplicada.
Se quiser acessar seu servidor local em um dispositivo Android, você precisará alterar algumas configurações. Digamos que sua máquina local esteja acessível na sua rede no endereço IP 10.0.0.1 . Você poderia iniciar seu servidor assim:
API_HOST=http://10.0.0.1:3000
SERVER_HOST=10.0.0.1
WEBPACK_SERVER_HOST=10.0.0.1
yarn amo:dev
No seu dispositivo Android, você poderá acessar o site de desenvolvimento em http://10.0.0.1:3000 .
NOTA : No momento, não é possível entrar com esta configuração porque o cliente de contas Mozilla redireciona para localhost:3000 . Você pode tentar uma abordagem diferente editando /etc/hosts em seu dispositivo para que localhost aponte para sua máquina de desenvolvimento, mas isso não foi totalmente testado.
Ao desenvolver localmente com um servidor webpack, o URL do ativo gerado aleatoriamente irá falhar em nossa Política de Segurança de Conteúdo (CSP) e sobrecarregar seu console com erros. Você pode desativar todos os erros de CSP definindo CSP como false em qualquer arquivo de configuração local, como local-development-amo.js . Exemplo:
module . exports = {
CSP : false ,
} ; A documentação que você está lendo agora está dentro do repositório de origem como Markdown com sabor do Github. Ao fazer alterações nesses arquivos, você pode criar uma solicitação pull para visualizá-los ou, melhor ainda, pode usar o grip para visualizar as alterações localmente. Depois de instalar grip , execute-o no diretório de origem assim:
grip .
Abra seu URL localhost e você verá o arquivo README.md renderizado. Conforme você faz edições, ele será atualizado automaticamente.
A seguir estão os scripts usados na implantação - geralmente você não precisará, a menos que esteja testando algo relacionado à implantação ou compilações.
Os env vars são:
NODE_ENV : o ambiente do nó, por exemplo, production ou developmentNODE_CONFIG_ENV : o nome da configuração a ser carregada, por exemplo, dev , stage , prod| Roteiro | Descrição |
|---|---|
| início do fio | Inicia o servidor expresso (requer env vars) |
| construção de fio | Constrói as bibliotecas (todos os aplicativos) (requer env vars) |
Exemplo: Construindo e executando uma instância de produção do aplicativo:
NODE_ENV=production NODE_CONFIG_ENV=prod yarn build
NODE_ENV=production NODE_CONFIG_ENV=prod yarn start
Para executar o aplicativo localmente no modo de produção, você precisará criar um arquivo de configuração para compilações de produção local. As compilações de produção podem ser construídas para diferentes ambientes: dev , stage e prod (controlados pelo NODE_CONFIG_ENV env var), mas apenas um arquivo de configuração extra é necessário para que esses ambientes sejam executados localmente.
Renomeie o arquivo denominado config/local.js.dist para config/local.js . Depois disso, reconstrua e reinicie usando yarn build e yarn start conforme documentado acima. Se você já usou 127.0.0.1 antes com uma configuração diferente, certifique-se de limpar seus cookies. A aplicação deverá estar disponível em: http://127.0.0.1:4000/.
NOTA : No momento, não é possível fazer login usando esta abordagem.
Você pode verificar qual commit do addons-frontend está implantado, quais experimentos A/B estão em execução ou quais sinalizadores de recursos estão habilitados fazendo uma solicitação como esta:
curl https://addons-dev.allizom.org/__frontend_version__
{
"build": "https://circleci.com/gh/mozilla/addons-frontend/10333",
"commit": "47edfa6f24e333897b25516c587f504e294e8fa9",
"experiments": {
"homeHero": true
},
"feature_flags": {
"enableFeatureAMInstallButton": true,
"enableFeatureStaticThemes": true
},
"source": "https://github.com/mozilla/addons-frontend",
"version": ""
}
Isso retornará uma resposta 415 se um arquivo version.json não existir no diretório raiz. Esse arquivo normalmente é gerado pelo processo de implantação.
Para consistência com scripts de monitoramento, os mesmos dados podem ser recuperados nesta URL:
curl https://addons-dev.allizom.org/__version__
Você pode instalar a extensão amo-info para visualizar facilmente essas informações.
Este projeto também contém código para construir uma biblioteca chamada addons-frontend-blog-utils e oferece os seguintes comandos:
yarn build:blog-utils-dev : construa a biblioteca, inicie um observador para reconstruir a biblioteca na mudança e forneça uma página de desenvolvimento em http://127.0.0.1:11000yarn build:blog-utils-prod : constrói a biblioteca no modo de produçãoEsta biblioteca foi projetada exclusivamente para funcionar com addons-blog.
Para publicar uma nova versão de addons-frontend-blog-utils , uma tag especial deve ser enviada ao repositório principal. O nome da tag deve começar com blog-utils- e geralmente contém o número da versão. Isso pode ser automatizado usando o seguinte comando:
npm version [major|minor|patch]
Emitir este comando do branch master atualizará a versão no package.json , criará um commit e criará uma tag. Envie este commit e a tag para o repositório principal.
Nota: Quando uma nova versão addons-frontend-blog-utils é mesclada no addons-blog, você deve publicar uma nova versão do tema WordPress. Por favor, siga estas instruções no repositório do addons-blog.
