digital form builder

Générateur de formulaires numériques XGov

cotisations

Les problèmes et les demandes de tirage sont les bienvenus. Veuillez d'abord vérifier CONTRIBUTING.md !

Ce référentiel est un dépôt mono pour

• @xgovformbuilder/runner - Serveur Hapi qui peut « exécuter » un formulaire à partir d'un fichier JSON
• @xgovformbuilder/designer - Une application React pour aider à la création de formulaires
• @xgovformbuilder/model - Sert le modèle de données et d'autres assistants
• @xgovformbuilder/e2e - tests de bout en bout

Les dépôts proviennent du générateur de formulaires numériques de DEFRA.

Il s'agit d'un référentiel d'espaces de travail Yarn 2 sans installation (qui se rapproche de celui-ci). .yarnrc.yml nous permet d'aligner nos environnements de fil. Veuillez valider tous les plugins dans .yarn, mais ne validez pas votre .yarn/cache. CI sauvegardera et restaurera les caches.

Les espaces de travail s'occuperont de la liaison symbolique des packages, nous n'avons donc pas besoin d'exécuter manuellement yarn link . Il s'occupera également du levage des node_modules pour tous les packages partagés entre les dépôts, réduisant ainsi les temps d'installation. J'espère que tout fonctionnera™️.

Consultez également les fichiers README du dépôt individuel pour plus d'informations :

• coureur README
• concepteur README
• modèle LISEZMOI
• e2e (tests de fumée) README

Installation

Exécutez toujours les scripts à partir du répertoire racine.

1. Assurez-vous que vous utilisez le nœud 20 node --version .
2. Assurez-vous que Yarn 1.22+ est installé. Vous n'avez pas besoin d'installer Yarn 2.4+, Yarn détectera le binaire Yarn 2 dans .yarn et qui sera utilisé.
3. Si vous utilisez le concepteur :
   • Notez que le concepteur nécessite que le programme d'exécution s'exécute avec les paramètres par défaut NODE_ENV=development (voir runner/config/development.json) pour permettre la publication et la prévisualisation des formulaires pendant la conception.
4. Exécutez la commande $ yarn pour installer toutes les dépendances dans tous les espaces de travail.
5. Exécutez $ yarn build pour créer tous les espaces de travail (cela est nécessaire car les dépendances peuvent dépendre les unes des autres).

Comme déjà mentionné, exécutez toujours les scripts à partir du répertoire racine. car les espaces de travail n'ont pas de scripts ou de packages que vous devez exécuter à partir de leurs dossiers et en s'exécutant dans le répertoire racine, Yarn 2 peut résoudre correctement les scripts/packages.

Pour en savoir plus sur les espaces de travail, consultez ces liens :

• Espaces de travail dans Yarn
• Espaces de travail

Je veux...

exécuter le script d'un espace de travail spécifique

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

par exemple : yarn designer start ou yarn runner add babel-core --dev

exécuter un script pour chacun des espaces de travail

$ yarn workspaces foreach run name-of-script

surveiller et créer des changements dans tous les dépôts

Je ne le recommanderais pas à moins d'avoir un processeur costaud.

$ yarn watch

ajouter une dépendance à tous les espaces de travail

$ yarn add packagename

créer un nouvel espace de travail

1. créez un nouveau répertoire pour l'espace de travail et lancez-le
   1. $ mkdir myNewLib
   2. $ cd myNewlib
   3. $ yarn init
2. dans le package.json racine.json
   1. ajoutez myNewLib à l'objet workspaces .

Dépannage

Si vous rencontrez des problèmes, soumettez un problème ou envoyez un message via gitter.

Erreur : ENOENT : aucun fichier ou répertoire de ce type, scandir 'xxx/node_modules/node-sass/vendor'

/vendor n'est pas présent car il n'a pas été construit ou reconstruit. Vous pouvez également rencontrer ce problème avec core-js , fsevents , nodemailer etc. $ yarn rebuild pour reconstruire tous les packages $ yarn rebuild only node-sass pour reconstruire uniquement node-sass

CI

Nous utilisons les actions GitHub pour exécuter notre processus CI. Consultez une visualisation du flux de travail ici.

Gestion des versions

Les numéros de version s'incrémenteront automatiquement en fonction des messages de validation et de SemVer (Major.Minor.Patch). Lors de la fusion, ajoutez à votre commit de fusion ce qui suit :

• major: ou breaking: - par exemple, breaking: removing feature X . Cela incrémentera la version MAJEURE - par exemple : 1.1.0 à 2.0.0
• minor: ou feature: - par exemple, feature: new component . Cela incrémentera la version MINEURE - par exemple : 1.1.0 à 1.2.0
• patch: ou fix: - par exemple, fix: url bug - cela incrémentera la version du PATCH - par exemple : 1.0.0 à 1.0.1 (cela se produira également par défaut)

Environnement de développement

Le workflow de développement est déclenché chaque fois qu'un PR est fusionné avec le principal, et vous pouvez le surveiller dans l'onglet d'action du référentiel.

Le flux de travail contient deux tâches distinctes qui s'exécutent en parallèle, une pour l'application Runner et une autre pour l'application Designer.

Les deux emplois fonctionnent comme suit :

1. Créez l'image Docker avec toutes les dépendances.
2. Transférez l’image vers Heroku Container Registry.
3. Libérez la dernière image.

Les dernières versions seront exécutées ici : Runner / Designer.

Tests de fumée

Une série de tests de fumée est effectuée sur tous les PR. Il existe une tâche Cron qui exécute des tests de fumée sur les déploiements Heroku et est programmée pour s'exécuter chaque jour à minuit.

Une suite héritée de tests de fumée peut être trouvée dans ce référentiel. Ils ont été supprimés afin que le projet puisse s'exécuter sur le nœud 18.

Les tests de fumée seront migrés pour utiliser cypress.io dans les mois à venir.