digital form builder

Creador de formularios digitales XGov

contribuciones

Los problemas y las solicitudes de extracción son bienvenidos. ¡Primero consulte CONTRIBUTING.md!

Este repositorio es un repositorio mono para

• @xgovformbuilder/runner - Servidor Hapi que puede 'ejecutar' un formulario desde un archivo JSON
• @xgovformbuilder/designer: una aplicación de React para ayudar en la creación de formularios
• @xgovformbuilder/model: sirve el modelo de datos y otros ayudantes
• @xgovformbuilder/e2e - pruebas de extremo a extremo

Los repositorios se derivan del creador de formularios digitales de DEFRA.

Este es un repositorio de espacios de trabajo de Yarn 2 (que se está acercando a) sin instalación. .yarnrc.yml nos permite alinear nuestros entornos de hilo. Confirme cualquier complemento en .yarn, pero no confirme su .yarn/cache. CI guardará y restaurará los cachés.

Los espacios de trabajo se encargarán de vincular simbólicamente los paquetes, por lo que no tenemos que ejecutar manualmente yarn link . También se ocupará de aumentar los node_modules para cualquier paquete que se comparta entre los repositorios, disminuyendo así los tiempos de instalación. Ojalá todo funcione™️.

Consulte también los archivos README del repositorio individual para obtener información adicional:

• corredor README
• Léame del diseñador
• modelo LÉAME
• e2e (pruebas de humo) LÉAME

Configuración

Ejecute siempre scripts desde el directorio raíz.

1. Asegúrese de estar utilizando el nodo 20 node --version .
2. Asegúrate de tener instalado el hilo 1.22+. No es necesario instalar Yarn 2.4+, Yarn detectará el binario Yarn 2 dentro de .yarn y se utilizará.
3. Si usa el diseñador:
   • Tenga en cuenta que el diseñador requiere que el ejecutor se ejecute con la configuración predeterminada NODE_ENV=development (consulte runner/config/development.json) para permitir la publicación y la vista previa de formularios durante el diseño.
4. Ejecute el comando $ yarn para instalar todas las dependencias en todos los espacios de trabajo.
5. Ejecute $ yarn build para crear todos los espacios de trabajo (esto es necesario porque las dependencias pueden depender unas de otras).

Como ya se mencionó, ejecute siempre los scripts desde el directorio raíz. Debido a que los espacios de trabajo no tienen scripts o paquetes, debe ejecutarlos desde dentro de sus carpetas y, al ejecutarlos en el directorio raíz, Yarn 2 puede resolver los scripts/paquetes correctamente.

Para obtener más información sobre los espacios de trabajo, consulte estos enlaces:

• Espacios de trabajo en Yarn
• Espacios de trabajo

Yo quiero...

ejecutar un script de espacios de trabajo específicos

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

por ejemplo: yarn designer start o yarn runner add babel-core --dev

ejecutar un script para cada uno de los espacios de trabajo

$ yarn workspaces foreach run name-of-script

observe y cree cambios en todos los repositorios

No lo recomendaría a menos que tengas un procesador robusto.

$ yarn watch

agregar una dependencia a todos los espacios de trabajo

$ yarn add packagename

crear un nuevo espacio de trabajo

1. cree un nuevo directorio para el espacio de trabajo e inícielo
   1. $ mkdir myNewLib
   2. $ cd myNewlib
   3. $ yarn init
2. en el package.json raíz.json
   1. agregue myNewLib al objeto de workspaces .

Solución de problemas

Si tiene algún problema, envíe un problema o envíe un mensaje a través de gitter.

Error: ENOENT: no existe tal archivo o directorio, scandir 'xxx/node_modules/node-sass/vendor'

/vendor no está presente porque no se ha creado ni reconstruido. También puede tener este problema con core-js , fsevents , nodemailer , etc. $ yarn rebuild para reconstruir todos los paquetes $ yarn rebuild only node-sass para reconstruir solo node-sass

CI

Estamos utilizando acciones de GitHub para ejecutar nuestro proceso de CI. Vea una visualización del flujo de trabajo aquí.

Versionado

Los números de versión se incrementarán automáticamente según los mensajes de confirmación y SemVer (Major.Minor.Patch). Al fusionar, anteponga su confirmación de fusión con lo siguiente:

• major: o breaking: - por ejemplo, breaking: removing feature X Esto incrementará la versión PRINCIPAL, por ejemplo: 1.1.0 a 2.0.0
• minor: o feature: - por ejemplo, feature: new component . Esto incrementará la versión MENOR, por ejemplo: 1.1.0 a 1.2.0
• patch: o fix: - por ejemplo, fix: url bug - esto incrementará la versión del PATCH - por ejemplo: 1.0.0 a 1.0.1 (esto también sucederá de forma predeterminada)

Entorno de desarrollo

El flujo de trabajo de desarrollo se activa cada vez que un PR se fusiona con el principal y puede monitorearlo en la pestaña de acciones del repositorio.

El flujo de trabajo contiene dos trabajos independientes que se ejecutan en paralelo, uno para la aplicación Runner y otro para la aplicación Designer.

Ambos trabajos funcionan de la siguiente manera:

1. Cree la imagen de la ventana acoplable con todas las dependencias.
2. Envíe la imagen al Registro de contenedores Heroku.
3. Publicar la última imagen.

Las últimas versiones se ejecutarán aquí: Runner / Designer.

Pruebas de humo

Se realiza un conjunto de pruebas de humo contra todos los RP. Hay un trabajo cron que ejecuta pruebas de humo contra las implementaciones de Heroku y está programado para ejecutarse a medianoche todos los días.

En este repositorio se puede encontrar un conjunto heredado de pruebas de humo. Se eliminaron para que el proyecto pueda ejecutarse en el nodo 18.

Las pruebas de humo se migrarán para utilizar cypress.io en los próximos meses.