digital form builder

XGov Digital Form Builder

Beiträge

Issues und Pull Requests sind willkommen. Bitte überprüfen Sie zuerst CONTRIBUTING.md!

Dieses Repository ist ein Mono-Repo für

• @xgovformbuilder/runner – Hapi-Server, der ein Formular aus einer JSON-Datei „ausführen“ kann
• @xgovformbuilder/designer – Eine React-App zur Unterstützung bei der Formularerstellung
• @xgovformbuilder/model – Stellt das Datenmodell und andere Helfer bereit
• @xgovformbuilder/e2e – End-to-End-Tests

Die Repos stammen aus DEFRAs Digital Form Builder.

Dies ist ein Garn-2-Arbeitsbereichs-Repository (nahezu) ohne Installation. .yarnrc.yml ermöglicht es uns, unsere Garnumgebungen auszurichten. Bitte übertragen Sie alle Plugins in .yarn, aber übertragen Sie nicht Ihr .yarn/Cache. CI speichert und stellt die Caches wieder her.

Arbeitsbereiche kümmern sich um die Sym-Verknüpfung der Pakete, sodass wir yarn link nicht manuell ausführen müssen. Es kümmert sich auch um das Hochladen der node_modules für alle Pakete, die von den Repos gemeinsam genutzt werden, wodurch die Installationszeiten verkürzt werden. Hoffentlich funktioniert alles™️.

Weitere Informationen finden Sie auch in den einzelnen README-Dateien des Repos:

• runner README
• Designer README
• Modell README
• e2e (Rauchtests) README

Aufstellen

Führen Sie Skripte immer aus dem Stammverzeichnis aus.

1. Stellen Sie sicher, dass Sie Knoten 20 node --version verwenden.
2. Stellen Sie sicher, dass Garn 1.22+ installiert ist. Sie müssen Garn 2.4+ nicht installieren, Garn erkennt die Binärdatei Garn 2 in .yarn und wird verwendet.
3. Bei Verwendung des Designers:
   • Beachten Sie, dass der Designer erfordert, dass der Runner mit den Standardeinstellungen NODE_ENV=development ausgeführt wird (siehe runner/config/development.json), um das Posten und die Vorschau von Formularen während des Entwurfs zu ermöglichen.
4. Führen Sie den Befehl $ yarn aus, um alle Abhängigkeiten in allen Arbeitsbereichen zu installieren.
5. Führen Sie $ yarn build aus, um alle Arbeitsbereiche zu erstellen (dies ist erforderlich, da Abhängigkeiten voneinander abhängen können).

Wie bereits erwähnt, führen Sie Skripte immer aus dem Stammverzeichnis aus. Da Arbeitsbereiche keine Skripte oder Pakete haben, müssen Sie diese aus ihren Ordnern ausführen. Durch die Ausführung im Stammverzeichnis kann Yarn 2 die Skripte/Pakete ordnungsgemäß auflösen.

Weitere Informationen zu Arbeitsbereichen finden Sie unter den folgenden Links:

• Arbeitsbereiche in Yarn
• Arbeitsbereiche

Ich möchte...

Führen Sie das Skript eines bestimmten Arbeitsbereichs aus

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

Beispiel: yarn designer start oder yarn runner add babel-core --dev

Führen Sie für jeden Arbeitsbereich ein Skript aus

$ yarn workspaces foreach run name-of-script

Beobachten und erstellen Sie Änderungen in allen Repos

Ich würde es nicht empfehlen, es sei denn, Sie haben einen leistungsstarken Prozessor.

$ yarn watch

Fügen Sie allen Arbeitsbereichen eine Abhängigkeit hinzu

$ yarn add packagename

Erstellen Sie einen neuen Arbeitsbereich

1. Erstellen Sie ein neues Verzeichnis für den Arbeitsbereich und initieren Sie es
   1. $ mkdir myNewLib
   2. $ cd myNewlib
   3. $ yarn init
2. im Stammverzeichnis package.json
   1. Fügen Sie myNewLib zum workspaces -Objekt hinzu.

Fehlerbehebung

Wenn Sie Probleme haben, reichen Sie ein Problem ein oder senden Sie eine Nachricht über Gitter.

Fehler: ENOENT: keine solche Datei oder kein solches Verzeichnis, Scandir „xxx/node_modules/node-sass/vendor“

/vendor ist nicht vorhanden, da es weder erstellt noch neu erstellt wurde. Dieses Problem kann auch bei core-js , fsevents , nodemailer usw. auftreten. $ yarn rebuild um alle Pakete neu zu erstellen. $ yarn rebuild only node-sass um nur Node-Sass neu zu erstellen

CI

Wir verwenden GitHub-Aktionen, um unseren CI-Prozess auszuführen. Sehen Sie sich hier eine Visualisierung des Workflows an.

Versionierung

Versionsnummern werden automatisch basierend auf Commit-Nachrichten und SemVer (Major.Minor.Patch) erhöht. Stellen Sie Ihrem Merge-Commit beim Zusammenführen Folgendes voran:

• major: oder breaking: – zum Beispiel breaking: removing feature X . Dadurch wird die MAJOR-Version erhöht – zum Beispiel: 1.1.0 auf 2.0.0
• minor: oder feature: – zum Beispiel feature: new component . Dadurch wird die MINOR-Version erhöht – zum Beispiel: 1.1.0 auf 1.2.0
• patch: oder fix: – zum Beispiel fix: url bug – dadurch wird die PATCH-Version erhöht – zum Beispiel: 1.0.0 auf 1.0.1 (dies geschieht auch standardmäßig)

Entwicklungsumgebung

Der Entwicklungsworkflow wird immer dann ausgelöst, wenn ein PR mit dem Hauptprojekt zusammengeführt wird, und Sie können ihn auf der Registerkarte „Aktion“ des Repositorys überwachen.

Der Workflow enthält zwei separate Jobs, die parallel ausgeführt werden, einer für den Runner und einer für die Designer-Anwendung.

Beide Jobs funktionieren wie folgt:

1. Erstellen Sie das Docker-Image mit allen Abhängigkeiten.
2. Bild an Heroku Container Registry übertragen.
3. Geben Sie das neueste Bild frei.

Die neuesten Veröffentlichungen laufen hier: Runner / Designer.

Rauchtests

Für alle PRs wird eine Reihe von Rauchtests durchgeführt. Es gibt einen Cron-Job, der Rauchtests für die Heroku-Bereitstellungen durchführt und täglich um Mitternacht ausgeführt werden soll.

Eine ältere Suite von Rauchtests finden Sie in diesem Repository. Sie wurden entfernt, damit das Projekt auf Knoten 18 laufen kann.

Rauchtests werden in den kommenden Monaten auf die Verwendung von cypress.io migriert.