@defra/forms-engine-plugin 0.0.6 → 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +68 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -4,6 +4,33 @@ The `@defra/forms-engine-plugin` is a [plugin](https://hapi.dev/tutorials/plugin
|
|
|
4
4
|
|
|
5
5
|
It is designed to be embedded in the frontend of a digital service and provide a convenient, configuration driven approach to building forms that are aligned to [GDS Design System](https://design-system.service.gov.uk/) guidelines.
|
|
6
6
|
|
|
7
|
+
## Table of Contents
|
|
8
|
+
|
|
9
|
+
- [Installation](#installation)
|
|
10
|
+
- [Dependencies](#dependencies)
|
|
11
|
+
- [Setup](#setup)
|
|
12
|
+
- [Form Config](#form-config)
|
|
13
|
+
- [Static Assets and Styles](#static-assets-and-styles)
|
|
14
|
+
- [Example](#example)
|
|
15
|
+
- [Environment Variables](#environment-variables)
|
|
16
|
+
- [Options](#options)
|
|
17
|
+
- [Services](#services)
|
|
18
|
+
- [Custom Controllers](#custom-controllers)
|
|
19
|
+
- [Custom Filters](#custom-filters)
|
|
20
|
+
- [Custom Cache](#custom-cache)
|
|
21
|
+
- [Exemplar](#exemplar)
|
|
22
|
+
- [Templates](#templates)
|
|
23
|
+
- [Template Data](#template-data)
|
|
24
|
+
- [Liquid Filters](#liquid-filters)
|
|
25
|
+
- [Examples](#examples)
|
|
26
|
+
- [Templates and Views: Extending the Default Layout](#templates-and-views-extending-the-default-layout)
|
|
27
|
+
- [Publishing the Package](#publishing-the-package)
|
|
28
|
+
- [Semantic Versioning Control](#semantic-versioning-control)
|
|
29
|
+
- [Major-Version Release Branches](#major-version-release-branches)
|
|
30
|
+
- [Manual Workflow Triggers](#manual-workflow-triggers)
|
|
31
|
+
- [Workflow Triggers](#workflow-triggers)
|
|
32
|
+
- [Safety and Consistency](#safety-and-consistency)
|
|
33
|
+
|
|
7
34
|
## Installation
|
|
8
35
|
|
|
9
36
|
`npm install @defra/forms-engine-plugin --save`
|
|
@@ -209,7 +236,7 @@ The following elements support [LiquidJS templates](https://liquidjs.com/):
|
|
|
209
236
|
- Html (guidance) component **content**
|
|
210
237
|
- Summary component **row** key title (check answers and repeater summary)
|
|
211
238
|
|
|
212
|
-
### Template
|
|
239
|
+
### Template Data
|
|
213
240
|
|
|
214
241
|
The data the templates are evaluated against is the raw answers the user has provided up to the page they're currently on.
|
|
215
242
|
For example, given a YesNoField component called `TKsWbP`, the template `{{ TKsWbP }}` would render "true" or "false" depending on how the user answered the question.
|
|
@@ -296,3 +323,43 @@ The `forms-engine-plugin` path to add can be imported from:
|
|
|
296
323
|
Which can then be appended to the `node_modules` path `node_modules/@defra/forms-engine`.
|
|
297
324
|
|
|
298
325
|
The main template layout is `govuk-frontend`'s `template.njk` file, this also needs to be added to the `path`s that nunjucks can look in.
|
|
326
|
+
|
|
327
|
+
## Publishing the Package
|
|
328
|
+
|
|
329
|
+
Our GitHub Actions workflow (`publish.yml`) is set up to make publishing a breeze, using semantic versioning and a variety of release strategies. Here's how you can make the most of it:
|
|
330
|
+
|
|
331
|
+
### Semantic Versioning Control
|
|
332
|
+
|
|
333
|
+
- **Patch Versioning**: This happens automatically whenever you merge code changes into `main` or any release branch.
|
|
334
|
+
- **Minor and Major Bumps**: You can control these by making empty commits with specific hashtags:
|
|
335
|
+
- Use `#minor` for a minor version bump.
|
|
336
|
+
- Use `#major` for a major version bump.
|
|
337
|
+
|
|
338
|
+
**Example Commands**:
|
|
339
|
+
|
|
340
|
+
```bash
|
|
341
|
+
git commit --allow-empty -m "chore(release): #minor" # Minor bump
|
|
342
|
+
git commit --allow-empty -m "chore(release): #major" # Major bump
|
|
343
|
+
```
|
|
344
|
+
|
|
345
|
+
### Major-Version Release Branches
|
|
346
|
+
|
|
347
|
+
- **Branch Naming**: Stick to `release/vX` (like `release/v1`, `release/v2`).
|
|
348
|
+
- **Independent Versioning**: Each branch has its own versioning and publishes to npm with a unique dist-tag (like `2x` for `release/v2`).
|
|
349
|
+
|
|
350
|
+
### Manual Workflow Triggers
|
|
351
|
+
|
|
352
|
+
- **Customizable Options**: You can choose the type of version bump, specify custom npm tags, and use dry run mode for testing. Dry-run is enabled by default.
|
|
353
|
+
- **Special Releases**: Perfect for beta releases or when you need to publish outside the usual process.
|
|
354
|
+
|
|
355
|
+
### Workflow Triggers
|
|
356
|
+
|
|
357
|
+
1. **Standard Development Flow**: Merging PRs to `main` automatically triggers a patch bump and publishes with the `beta` tag.
|
|
358
|
+
2. **Backporting**: Cherry-pick fixes to release branches for patch bumps with specific tags (like `2x`).
|
|
359
|
+
3. **Version Bumps**: Use empty commits for minor or major bumps.
|
|
360
|
+
4. **Manual Releases**: Trigger these manually for special cases like beta or release candidates.
|
|
361
|
+
|
|
362
|
+
### Safety and Consistency
|
|
363
|
+
|
|
364
|
+
- **Build Process**: Every publishing scenario includes a full build to ensure everything is in top shape, except for files like tests and lint rules.
|
|
365
|
+
- **Tagging Safety**: We prevent overwriting the `beta` tag by enforcing custom tags for non-standard branches. The default is set to `beta`. For release branches, the tag will be picked up from the release branch itself.
|