digital form builder

Construtor de Formulários Digitais XGov

contribuições

Problemas e solicitações pull são bem-vindos. Por favor, verifique CONTRIBUTING.md primeiro!

Este repositório é um repositório mono para

• @xgovformbuilder/runner - Servidor Hapi que pode 'executar' um formulário a partir de um arquivo JSON
• @xgovformbuilder/designer – Um aplicativo React para auxiliar na construção de formulários
• @xgovformbuilder/model – Atende o modelo de dados e outros auxiliares
• @xgovformbuilder/e2e - testes de ponta a ponta

Os repositórios são derivados do construtor de formulários digitais do DEFRA.

Este é um repositório de espaços de trabalho do Yar 2 com instalação zero (chegando perto de). .yarnrc.yml nos permite alinhar nossos ambientes de fios. Por favor, envie quaisquer plug-ins em .yarn, mas não envie seu .yarn/cache. CI salvará e restaurará os caches.

Os espaços de trabalho lidarão com a vinculação simbólica dos pacotes, portanto, não precisamos executar manualmente yarn link . Ele também lidará com o içamento de node_modules para quaisquer pacotes compartilhados entre os repositórios, diminuindo assim o tempo de instalação. Espero que tudo funcione™️.

Consulte também os arquivos README do repositório individual para obter informações adicionais:

• corredor LEIA-ME
• LEIA-ME do designer
• modelo LEIA-ME
• e2e (testes de fumaça) LEIA-ME

Configurar

Sempre execute scripts do diretório raiz.

1. Certifique-se de estar usando o nó 20 node --version .
2. Certifique-se de ter o fio 1.22+ instalado. Você não precisa instalar o Yarn 2.4+, o Yarn detectará o binário do Yarn 2 dentro de .yarn e ele será usado.
3. Se estiver usando o designer:
   • Observe que o designer exige que o executor esteja em execução com as configurações padrão NODE_ENV=development (consulte runner/config/development.json) para permitir a postagem e a visualização de formulários durante o design.
4. Execute o comando $ yarn para instalar todas as dependências em todos os espaços de trabalho.
5. Execute $ yarn build para construir todos os espaços de trabalho (isso é necessário porque as dependências podem depender umas das outras).

Como já mencionado, sempre execute scripts do diretório raiz. porque os espaços de trabalho não possuem scripts ou pacotes que você precisa executar de dentro de suas pastas e executando no diretório raiz o yarn 2 pode resolver os scripts/pacotes corretamente.

Para saber mais sobre espaços de trabalho, verifique estes links:

• Espaços de trabalho em Yarn
• Espaços de trabalho

Eu quero...

execute um script de espaços de trabalho específicos

$ yarn [runner|designer|model] name-of-script

por exemplo: yarn designer start ou yarn runner add babel-core --dev

execute um script para cada um dos espaços de trabalho

$ yarn workspaces foreach run name-of-script

observe e crie mudanças em todos os repositórios

Eu não recomendaria isso, a menos que você tenha um processador robusto.

$ yarn watch

adicione uma dependência a todos os espaços de trabalho

$ yarn add packagename

criar um novo espaço de trabalho

1. crie um novo diretório para o espaço de trabalho e faça o yarn init nele
   1. $ mkdir myNewLib
   2. $ cd myNewlib
   3. $ yarn init
2. na raiz package.json
   1. adicione myNewLib ao objeto de workspaces .

Solução de problemas

Se você tiver algum problema, envie um problema ou envie uma mensagem via gitter.

Erro: ENOENT: arquivo ou diretório inexistente, scandir 'xxx/node_modules/node-sass/vendor'

/vendor não está presente porque não foi compilado ou reconstruído. Você também pode $ yarn rebuild esse problema com $ yarn rebuild only node-sass core-js , fsevents , nodemailer etc.

IC

Estamos usando ações do GitHub para executar nosso processo de CI. Veja uma visualização do fluxo de trabalho aqui.

Versionamento

Os números de versão serão incrementados automaticamente com base nas mensagens de commit e SemVer (Major.Minor.Patch). Ao mesclar, acrescente o seguinte ao seu commit de mesclagem:

• major: ou breaking: - por exemplo, breaking: removing feature X . Isto irá incrementar a versão PRINCIPAL - por exemplo: 1.1.0 a 2.0.0
• minor: ou feature: - por exemplo, feature: new component . Isto irá incrementar a versão MINOR - por exemplo: 1.1.0 para 1.2.0
• patch: ou fix: - por exemplo, fix: url bug - isso irá incrementar a versão do PATCH - por exemplo: 1.0.0 a 1.0.1 (isso também acontecerá por padrão)

Ambiente de desenvolvimento

O fluxo de trabalho de desenvolvimento é acionado sempre que um PR é mesclado no principal e você pode monitorá-lo na guia de ação do repositório.

O fluxo de trabalho contém dois trabalhos separados executados em paralelo, um para o Runner e outro para o aplicativo Designer.

Ambos os trabalhos funcionam da seguinte forma:

1. Crie a imagem do Docker com todas as dependências.
2. Envie a imagem para o Heroku Container Registry.
3. Divulgue a imagem mais recente.

Os últimos lançamentos estarão rodando aqui: Runner/Designer.

Testes de fumaça

Um conjunto de testes de fumaça é executado em todos os PRs. Existe um Cron Job que executa testes de fumaça nas implantações do Heroku e está programado para ser executado à meia-noite todos os dias.

Um conjunto legado de testes de fumaça pode ser encontrado neste repositório. Eles foram removidos para que o projeto possa ser executado no nó 18.

Os testes de fumaça serão migrados para usar o cypress.io nos próximos meses.