@madgex/fert 7.0.12 → 7.0.13

package/.github/workflows/release.yml

@@ -19,7 +19,7 @@ jobs:
         uses: actions/setup-node@v4
         with:
           cache: npm
-          node-version: 22
+          node-version: "lts/*"
 
       - name: Setup SSH Keys and known_hosts
         env:

package/bin/commands/build-tasks/bundle-entry.js

@@ -1,6 +1,5 @@
 import path from 'node:path';
 import { pathToFileURL } from 'node:url';
-import merge from 'lodash/merge.js';
 import * as vite from 'vite';
 import { buildExternalAssets } from './build-external-assets.js';
 import { log } from '../../utils/logging.js';
@@ -34,7 +33,7 @@ export async function bundleEntry(fertConfig, options = {}) {
     },
   };
 
-  merge(viteConfig, dynamicOptions);
+  viteConfig = vite.mergeConfig(viteConfig, dynamicOptions);
 
   await vite.build(viteConfig);
 

package/bin/commands/dev-server.js

@@ -3,7 +3,7 @@ import path from 'node:path';
 import { glob } from 'node:fs/promises';
 import chalk from 'chalk';
 import open from 'open';
-import chokidar from 'chokidar4';
+import chokidar from 'chokidar5';
 import { resolveConfig, findFertConfigDir } from '../utils/index.js';
 import { validateLocalConfigs } from '../utils/configs.js';
 import { devServer } from '../../server/server.js';

package/bin/utils/cpid-lookup.js

@@ -1,4 +1,3 @@
-import axios from 'axios';
 import chalk from 'chalk';
 import { log } from '../utils/logging.js';
 import { PROPERTY_ID_API, ONE_WEEK } from '../../constants.js';
@@ -10,30 +9,29 @@ const cache = new PersistentCacheWithTtl('cpid-cache', {
 
 export async function doCpidLookup(clientPropertyId) {
   const API_URL = new URL(clientPropertyId, PROPERTY_ID_API).toString();
-
-  const results = await axios
-    .get(API_URL, { timeout: 5000 })
-    .then((res) => {
-      return res.data.data;
-    })
-    .catch((error) => {
-      log.error(
-        `Unable to lookup CPID [${chalk.yellow(
-          clientPropertyId,
-        )}] from ${chalk.cyan(API_URL)}: ${chalk.redBright(error.message)}\n`,
-      );
-
-      throw Error(error.message);
-    });
-
-  const { brandName, parentId: parentCpid } = results;
-
-  return {
-    brandName,
-    parentCpid: parentCpid ?? false,
-    rootClientPropertyId: parentCpid ?? clientPropertyId,
-    isAffiliate: !!parentCpid,
-  };
+  try {
+    const results = await fetch(API_URL, { signal: AbortSignal.timeout(5000) });
+    if (!results.ok) {
+      const errorMessage = await results.text();
+      throw new Error(`${results.status} - ${errorMessage}`);
+    }
+    const { data } = await results.json();
+    const { brandName, parentId: parentCpid } = data;
+    return {
+      brandName,
+      parentCpid: parentCpid ?? false,
+      rootClientPropertyId: parentCpid ?? clientPropertyId,
+      isAffiliate: !!parentCpid,
+    };
+  } catch (error) {
+    log.error(
+      `Unable to lookup CPID [${chalk.yellow(
+        clientPropertyId,
+      )}] from ${chalk.cyan(API_URL)}: ${chalk.redBright(error.message)}\n`,
+    );
+
+    throw error;
+  }
 }
 
 export async function cpidLookup(clientPropertyId, options = {}) {

package/docs/BRANDING_REPO_OVERVIEW.md

@@ -0,0 +1,113 @@
+## Branding Repository Overview
+
+## What is a Branding Repo?
+
+These git repositories contain the Branding, Header & Footers, Configs and other assets for **one** client, and **one** client is represented by a `clientPropertyId (CPID)`, where the repository name will be include the CPID `madgex-<CLIENT_PROPERTY_ID>` e.g. https://github.com/wiley/madgex-ff6102ff-0f4b-43d1-a2c7-83b835b8dee5 .
+
+This means there is one Branding Repo per affiliate too, as well as the regular Parent site.
+
+> 💁 For example, BMJJobs has 3 Branding Repos.
+>
+> 1. "Parent" - https://github.com/wiley/madgex-8b60330c-d2ec-4cba-b018-acb84bd97719
+> 2. "Affiliate Careers" - https://github.com/wiley/madgex-1a70fdf6-1fa8-4c37-9968-b88f195ff2d8
+> 3. "Affiliate HealthCareers" - https://github.com/wiley/madgex-33837840-d7e8-4453-82d7-8b0ed7c6efe6
+
+### Services in the Branding Repo
+
+A Branding Repo will contain **one or many** `services`. Each `service` follows the same structure stated below.
+Outside of some generic stuff like `config`, the majority of your work will be done inside a service folder.
+
+The `serviceName` of a `service` is directly tied to the V6 `service` name its for:
+
+- [`jobseekers-frontend`](https://github.com/wiley/madgex-jobseekers-frontend/), **also consumed by `V5 ResponsiveJobseekersSite`**
+- [`recruiterservices-frontend`](https://github.com/wiley/madgex-recruiterservices-frontend/), **also consumed by `V5 RecruiterSite`**
+
+> [!TIP]
+> **`recruiterservices-frontend` will only be in a "Parent" Branding Repo**, as there is only 1 Recruiter Site, and never separate Recruiter Sites for affiliates. Do not put `recruiterservices-frontend` in an "Affiliate" Branding Repo.
+
+### Branding Repo Contents and Structure
+
+This structure **must be followed and are required unless stated**, but some folders and files are optional:
+
+<pre>
+.
+├── config <strong>(optional, configs must go in here)</strong>
+│   ├── JobBoardConfig.careerpathCountryIso.json 
+│   ├── ...
+├── fert.config.js
+├── jenkinsfile
+├── .gitignore
+├── package.json
+└── services
+    ├── &lt;service-folder-name&gt;
+    │   ├── brand.json
+    │   ├── fert.service.config.js
+    │   ├── public <strong>(asset must go in here)</strong>
+    │   │   ├── fonts
+    │   │   │   ├── my-font.woff2 <strong>(optional)</strong>
+    │   │   ├── images
+    │   │   │   ├── favicon.ico
+    │   │   │   └── logo.svg <strong>(optional, recommended)</strong>
+    │   │   ├── translation.json <strong>(optional)</strong>
+    │   │   ├── redirects.csv <strong>(optional)</strong>
+    │   │   ├── ...
+    │   ├── src
+    │   │   ├── css
+    │   │   │   └── styles.css <strong>(optional)</strong>
+    │   │   ├── index.js
+    │   │   ├── ...
+    │   └── templates
+    │       ├── footer.njk
+    │       └── header.njk
+    ├── &lt;another-service-folder-name&gt;
+    │   ├── ...
+
+
+</pre>
+
+- you must put **configs** in the `/config` folder
+- **service templates** `header.njk` and `footer.njk` **must exist**, these are expected to exist by the header-footer-podlet service. e.g. `/services/<service-folder-name>/templates/header.njk`
+- **translation overrides** must be the file `/services/<service-folder-name>/public/translation.json`
+- [V6 Redirects](https://wiley-global.atlassian.net/wiki/spaces/MGXDC/pages/100008912/Redirects+on+V6+Jobseekers+Frontend) must be the file `/services/<service-folder-name>/public/redirects.csv`
+- **service assets** must go in `/services/<service-folder-name>/public/**/*`.
+  - This serves a dual purpose: this whole `public` folder is uploaded on deployment
+  - It is also the special folder that the `Vite` build system uses. When you reference `/public/<filename>` in your code this tells `Vite` its an asset it should know about e.g. `/public/fonts/my-font.woff2`
+- **package.json** - should contain at least `devDependencies` of `@madgex/fert`, and have `dev` and `build` scripts
+- The **CSS** for a service exists for 2 reasons: Font registration & Custom Header/Footer styling (not Themes) **only**. This means this file is cheekily doing 2 jobs, but must never have CSS for anything else in it.
+- **brand.json** - contains design system tokens and is the **only** way to customise site appearance (e.g. button colours, CTA backgrounds, ...). If something cannot be changed via a token, it is not customisable. We do not add CSS to work around this limitation—this ensures maintainability of both the design system and the platform.
+- **fert.config.js** - the root configuration file for FERT. Contains the `clientPropertyId` (CPID) that identifies which client this Branding Repo belongs to. This file is required and must exist at the repository root.
+
+```js
+// /fert.config.js
+module.exports = {
+  clientPropertyId: 'ff6102ff-0f4b-43d1-a2c7-83b835b8dee5', // required
+};
+```
+
+- **fert.service.config.js** - per-service configuration file that must exist in each service folder.
+
+```js
+// /services/<service-folder-name>/fert.service.config.js
+module.exports = {
+  serviceName: 'jobseekers-frontend', // required, `jobseekers-frontend`, `recruiterservices-frontend`
+  entry: './src/index.js', // required - almost always this path
+  // optional
+  externalAssets: {
+    links: ['https://fonts.googleapis.com/css2?family=Lato:ital,wght@0,400;0,700;1,400&display=swap'],
+    scripts: [],
+  },
+};
+```
+
+### How does a Branding Repo work?
+
+- We use [`@madgex/fert`](https://github.com/wiley/madgex-frontend-rollout-tool) to dev/build/publish Branding Repos and Configs.
+  - Locally you'll usually only use `dev` which should be `npm run dev`
+- Internally `"FERT"` runs a local server which contains a copy of the `header-footer-podlet` service used to render `header.njk` and `footer.njk` files.
+- `FERT` also includes a `Vite` dev server which compiles any JS, CSS and the `brand.json`.
+  - a Vite dev server is run for **each service**. `jobseekers-frontend` service might be on http://localhost:4001 whereas `recruiterservices-frontend` might be on http://localhost:4021.
+  - The service's `brand.json` is used to generate `CSS variables` and `JSON variables` files. `CSS variables` are used in conjunction with [`Madgex Design System CSS`](https://design-system.jb.dev.madgexhosting.net/)
+  - Like the Header and Footer, the Design System branding can be previewed via the page contents when viewing the Vite dev server page.
+- `FERT` is used on the [`nomad` Jenkins server](https://nomad.madgexhosting.net) to `build` the Branding Repo
+  - JS and CSS are compiled by Vite
+  - template, JS and CSS `/public/*` paths are replaced with public asset URLs like https://asset-relay.madgexjb.com/big-work-bag-6tORXNlh/images/logo.png . See [Asset Relay](https://github.com/wiley/madgex-asset-relay)

package/docs/CHECKLIST.md

@@ -0,0 +1,39 @@
+# Branding Repo Checklist
+
+## Generic
+
+- [ ] Create **non-master** branch of any new work, this will create a `dev` build/deployment and ensures V5 `UAT` will display the latest changes
+- [ ] Verify your **non-master** branch built and deployed successfully on [nomad](https://nomad.madgexhosting.net) before merging to master (don't want to wait the 5 minute delay? Click "Build now" on your branch, or "Scan multibranch pipeline now" to look for you new branch immediately)
+- [ ] Config files go in the `<root>/config/` folder
+
+## Services
+
+- [ ] Make sure all nav link URLs are correct
+- [ ] Ensure all asset paths pointing to local public folder begin with forward slash `/public`
+- [ ] Make sure you are not using any external assets like images where they might disappear/be blocked/cross domain issues. Download and put them in the `/public` folder instead
+  - This excludes links/scripts in `fert.service.config.js`
+- [ ] Store fonts locally in `/public/fonts` and register them in your css.
+  - Don't use Google Fonts API - download those fonts and register them in CSS
+  - Adobe fonts still need to use external link **registered in `fert.service.config.js`** (not in the CSS file directly)
+- [ ] Make sure the css file import is correct in `src/index.js` entry file. If you are not using a css file (no fonts to register) or the file does not exist, remove the import but keep `src/index.js` file even if its empty
+- [ ] If you have `.svg` files, ensure it has a `width` & `height` attribute on the `<svg>` element in the file, this ensures the browser knows its aspect ratio
+- [ ] 🚨 Don't override any `mds` CSS, you must use `brand.json`
+- [ ] Ensure images that are links have `alt` text. A link must have screen-readable text inside it
+  - [ ] Image alt text should reflect what you can visually see, if the image has visible text, put this in the alt text first. e.g. Logo visually says `"BMJ Jobs"` and links to homepage, you could have an alt text of `"BMJ Jobs - Home"`
+- [ ] the `/public/images/favicon.ico` file exists
+- [ ] Make sure each service has its own files, and has all required files. Remember **each service is standalone**, there is no sharing of assets, templates, brand.json or anything. Even if `brand.json` is duplicated for each service.
+
+## brand.json
+
+- [ ] Make sure you are overriding JSON that exists ([Make sure the structure matches the base JSON](https://github.com/wiley/madgex-design-system/tree/master/packages/%40madgex.design-system/src/tokens))
+- [ ] Don't override font sizes unless the client has some really strict requirements
+- [ ] Don't use `$type`, these are already internally specified, you only need to override `$value`.
+- [ ] Only override a token if its value is different than the default
+
+## Header/Footer Theme
+
+- [ ] Check locale is correct, e.g. `en-US` for american/canadian sites
+- [ ] Check `serviceName` matches your service, e.g. `jobseekers-frontend` for `jobseekers-frontend`
+- [ ] All macro **param names** and **`string` values** should be wrapped in `"double quotes"`. e.g. **Keep the macro input as JSON** so it can be easily copied back into Storybook
+  - Bad: `cssVarFontFamily: '"My Font", sans-serif'`
+  - Good: `"cssVarFontFamily": "\"My Font\", sans-serif"`

package/docs/GLOSSARY.md

@@ -0,0 +1,31 @@
+# Glossary
+
+### Affiliate
+
+Also known as a `"Network Skin"` in V5, this is a "child" of a "Parent" site. An "Affiliate" is actually a sub-set of data from the "Parent" site, you can think of it as a filtered view of the "Parent" that also includes its own Branding and customisations to appear like a separate site.
+
+In V6 each "Affiliate" gets its own `client-property-id`, so each "Affiliate" has its own [Branding Repo](BRANDING_REPO_OVERVIEW.md).
+
+### [Branding Repo](BRANDING_REPO_OVERVIEW.md)
+
+A git repository for each client, holding the Branding information, Header/Footer templates, fonts, configs, translation overrides, V6 Redirects etc. A repository name will be include the CPID `madgex-<CLIENT_PROPERTY_ID>` e.g. https://github.com/wiley/madgex-ff6102ff-0f4b-43d1-a2c7-83b835b8dee5 .
+
+### client
+
+Also known as a `client-property-id (CPID)` which represents a Parent client OR an affiliate. This means `BMJJobs` with 1 Parent and 2 Affiliates has **3** `client-property-id`s, and therefore **3** Branding Repos.
+
+### client-property-id (CPID)
+
+Main identifier for a `client` in V6. Everything hangs off this GUID, each V6 request contains a header `x-client-property-id` which V6 frontend services use to generate a page and fetch resources. A CPID exists for each Parent client and for each of its affiliates.
+
+### configs
+
+For Branding Repos, this means **V6** configs, which are `json` files in the `<root>/config` directory of each `Branding Repo`. For **V5** you should configure these in the `xml` files in `V5 Project Repo`.
+
+### [FERT (FrontEnd Rollout Tool)](../README.md)
+
+A commandline tool which provides a development environment (powered by Vite & local dev server), build process (Vite), deployment process (runs in Jenkins), Config validation and boilerplate generation (`npx @madgex/fert init` to set up an empty repo).
+
+### service/ serviceName
+
+Represents a service like the Jobseekers Frontend, or Recruiter Site. Almost always is **required to be the V6 name of the service**: `jobseekers-frontend` | `recruiterservices-frontend`

package/docs/README.md

@@ -0,0 +1,214 @@
+# Building Frontend Branding
+
+- [🐣 CHECKLIST](CHECKLIST.md)
+- [🧙 Glossary](GLOSSARY.md)
+- [🎓 Branding Repository Overview](BRANDING_REPO_OVERVIEW.md)
+- [⚽️ Headers and Footers with Themes](https://header-footer-podlet.job.madgexhosting.net/storybook/?path=/docs/getting-started--docs)
+- [🔀 V6 Redirects](https://wiley-global.atlassian.net/wiki/spaces/MGXDC/pages/100008912/Redirects+on+V6+Jobseekers+Frontend)
+
+## 🎒 Getting Started
+
+Check out [Branding Repository Overview](BRANDING_REPO_OVERVIEW.md) for the structure of a Branding Repo and its `services`, if you have not seen it yet.
+
+Find out your `Client Property ID` by visiting [Madgexverse](https://madgexverse.job.madgexhosting.net). If your CPID does not exist, you can not work on this Branding Repo right now.
+
+This will give you your repository `https://github.com/wiley/madgex-<CPID>` e.g. https://github.com/wiley/madgex-ff6102ff-0f4b-43d1-a2c7-83b835b8dee5. If this is a brand new client, the Branding Repo should be automatically created on `master` branch.
+
+> **Ask Systems why, if this is not automatically created**
+
+### If you have an **empty** Branding Repo (e.g. a git repository has been set up but has no files)
+
+- Switch into a new branch
+- `cd` into your cloned empty git repo. Use `npx @madgex/fert init .` and follow the prompts, this will populate your directory, including at least one `service` where the majority of the work will be done.
+- `npm i` install packages.
+
+### If you have an existing Branding Repo
+
+- switch into a new branch
+- You can add a new service folder to `<root>/services/<service-name>` (`jobseekers-frontend` or `recruiterservices-frontend`), following [the Branding Repo service structure here](BRANDING_REPO_OVERVIEW.md).
+- It is good practice to ensure `<root>/package.json` `@madgex/fert` version is the latest.
+
+> [!IMPORTANT]
+> To ensure you have the latest node_module packages (especially `header-footer-podlet` within fert), run `npm update`.
+
+- `npm run dev` to begin dev servers for all services. Each service will have its own development port, e.g. `jobseekers-frontend` service might be on http://localhost:4001 whereas `recruiterservices-frontend` might be on http://localhost:4021.
+  - These ports may change if they are not free (if you are running multiple Branding Repos at the same time!), another port will automatically be chosen
+
+> [!IMPORTANT]
+> Remember **each service is standalone**, there is no sharing of assets, templates, brand.json or anything. This means you might end up with duplicates between service like the `brand.json`.
+
+## 🎨 Service brand.json
+
+Using these [`base madgex-design-system JSON tokens`](https://github.com/wiley/madgex-design-system/tree/master/packages/%40madgex.design-system/src/tokens) as reference, override `$value`s using the same JSON structure in this single file.
+This JSON file exclusively controls the styling of the V6 pages (and even [emails](https://github.com/wiley/madgex-template-renderer/blob/8daf93aea7f2f1b937a0da39496b23657e118ba6/lib/templates/accountapproved.html.njk#L4) & [social images for jobs](https://github.com/wiley/madgex-display-image-render-api/blob/67e4a1087122329306278912704ca642933883ed/templates/ads/jobboard-basic/index.jsx#L14)).
+
+> [!IMPORTANT]
+> If branding can't be done here, do not add custom CSS, we should improve the tokens instead, however the tokens have been fairly stable for many years.
+
+Currently V5 does not use `madgex-design-system` and therefore does not use brand.json at all.
+
+> Coming soon? Automatic brand.json validation?
+
+## 🚧 Service Header & Footer templates
+
+### Themes vs Custom templates
+
+We much prefer to use [Themes](https://header-footer-podlet.job.madgexhosting.net/storybook/?path=/docs/getting-started--docs) (which are built-in to the header-footer-podlet service) for the `header.njk` and `footer.njk` templates. Themes are faster to make, reduces the amount of common errors, automatically gets updates and fixes. Theme CSS is isolated with ShadowDOM so they always look good on V5 or V6.
+
+Designers will try to use Themes for new projects and the output should look how they expect.
+
+Sometimes we convert pre-existing Custom Headers and Footers to Themes , even if this means small things change. These changes are usually passed to the project manager to verify they are OK to proceed with.
+
+Themes work better on V5 than Custom templates. If you must create Custom templates you will need to ensure the CSS acts the same way on both V5 and V6.
+
+### Custom template
+
+> Coming soon? Custom template starter-from-theme?
+
+Available global Nunjucks context:
+
+- `templatePath: string`: Required prefix for importing additional Nunjucks files e.g. `{%- include templatePath + './include/my-other-file.njk' -%}`
+- `path: string`: current page relative URL
+- `normaliseUrl: Filter`: removes trailing slash from a URL, e.g. `{{path === myNavLink | normaliseUrl }}`
+- `getServiceRoute(serviceRouterId,routeId,paramsObj,queryObj):Function` : [ usage](https://github.com/wiley/madgex-hapi-reverse-router/blob/master/packages/@madgex.hapi-reverse-router/README.md#usage-example)
+- `getAbsoluteServiceRoute(serviceRouterId,routeId,paramsObj,queryObj):Function` : [ usage](https://github.com/wiley/madgex-hapi-reverse-router/blob/master/packages/@madgex.hapi-reverse-router/README.md#usage-example)
+  - routeId reference for [`"jobseekersite"`](https://jobseekers-frontend.job.madgexhosting.net/api/routing-table/ff6102ff-0f4b-43d1-a2c7-83b835b8dee5)
+  - routeId reference for [`"recruitersite"`](https://recruiterservices-frontend.job.madgexhosting.net/api/routing-table/ff6102ff-0f4b-43d1-a2c7-83b835b8dee5)
+  - e.g. `{{getServiceRoute('jobseekersite', 'account.login', {}, {Pipline: path})}}`
+- `dayjs:Function`: like momentjs [see here](https://github.com/iamkun/dayjs/tree/dev?tab=readme-ov-file#api)
+
+## 🔠 Service V6 translations
+
+Each `service` in a branding repo may have **optional** translation overrides.
+
+These live at `<root>/services/<SERVICE_NAME>/public/translation.json`, e.g. https://github.com/wiley/madgex-ff6102ff-0f4b-43d1-a2c7-83b835b8dee5/blob/901e5b2295892747015bd1c9bab7ac307b4e2112/services/jobseekers-frontend/public/translation.json .
+
+Base reference for `en-GB` on [jobseekers-frontend](https://github.com/wiley/madgex-jobseekers-frontend/blob/master/locales/en-GB/translation.json).
+
+> Coming soon? Automatic translation validation?
+
+## ⚙️ Configs (V6)
+
+Configs live in the root of a Branding Repo like `<root>/config/` e.g. https://github.com/wiley/madgex-ff6102ff-0f4b-43d1-a2c7-83b835b8dee5/tree/master/config . Configs are service-agnostic and don't live in the service folders.
+
+Configs are validated in Jenkins for each branch of a Branding Repo and will block a deployment if they fail.
+
+### Common Configs for New Sites
+
+For a new site, the two configs most commonly changed are:
+
+- **[`JobBoardConfig.jobboardUserDataPreferenceSettings.json`](https://github.com/wiley/madgex-config-api-sdk/blob/465594b681724691853779b065cf9276f41f5327/schemas/JobBoardConfig.jobboardUserDataPreferenceSettings.js)** — Controls marketing preferences (e.g. 1st and 3rd party marketing checkboxes), user-related questions, and text displayed before or after marketing sections on forms.
+- **[`JobBoardConfig.jobboardCustomRoutes.json`](https://github.com/wiley/madgex-config-api-sdk/blob/465594b681724691853779b065cf9276f41f5327/schemas/JobBoardConfig.jobboardCustomRoutes.js)** — Customises URL paths for pages (e.g. renaming `/careers` to `/articles` for the article lister) and sets a `prefix` for reverse proxy setups (e.g. when hosting the job board at `bmj.com/careers`).
+
+### Config Reference
+
+We validate Configs on build, using a common package called `config-api-sdk` used on all V6 services. This holds reference to all configs [config-api-sdk](https://github.com/wiley/madgex-config-api-sdk/tree/master/schemas).
+These schemas are Joi validation files that expect your config files to be in a correct JSON format.
+
+Do not create config for any that are `read-only`, these are usually V5 Configs that need to be configured in the V5 Project Repo.
+
+> Coming soon? Automatic config validation at development?
+
+## 🗑️ Adverts (Header leaderboard)
+
+```html
+<div id="ad-leaderboard" class="hfp-leaderboard ad ad--leaderboard ad--leaderboard--empty"></div>
+```
+
+On Themes this empty div is waiting to be populated with GTM. The GTM ad script should provide its own padding. This ad div is outside of the ShadowDOM and thus is affected by the page's global CSS.
+
+On Custom templates you can choose to to include the ad div or not.
+
+## 🛠️ Build & Deployment pipeline
+
+Builds and deployments happen on the [`nomad` Jenkins server](https://nomad.madgexhosting.net), each branding repo has its own `job`, e.g. https://nomad.madgexhosting.net/job/madgex-ff6102ff-0f4b-43d1-a2c7-83b835b8dee5/
+
+While working on a **non-master** branch, builds in Jenkins can give you a good indication of everything working as it should and describe what exactly is being build and deployed, before the **master** branch is updated to build and deploy to production.
+
+**non-master** branches on a Branding Repo will trigger builds & deployment to the `development` (asset store) location. These builds will be available for V5 `Local Dev`, `UAT` `QA` & `any Unknown` environments.
+
+**master** branches will build and deploy to the `production` (asset store) location. These builds will be available for V6, and V5 `Staging` & `Production` environments.
+
+> [!IMPORTANT]
+> Remember deployments will happen automatically along with the build, on each branch updates.
+>
+> Currently it takes **less than 1 minute to build and deploy**, and may be a **5 minute polling** before branch changes are picked up.
+
+> [!TIP]
+> Builds & deployments **may take up to 5 minutes** to start on `nomad`. Don't want to wait? Click "Build now" on your branch, or "Scan multibranch pipeline now" to look for you new branch immediately.
+> <img src="./jenkins-build-now.png" width="500" />
+
+> [!TIP]
+> For new sites, the automatic build might not be enabled.
+> Go to the repo in `nomad` and check in `Configuration` that the checkbox in `Scan Multibranch Pipeline Triggers` is ticked and the interval is set to 5min.
+
+> [!TIP]
+> Failed builds will be automatically posted to the [Teams Channel pipline-alerts-fed](https://teams.microsoft.com/l/channel/19%3Aaff4053b353c49e1a4f401982db1fb6f%40thread.tacv2/pipeline-alerts-fed?groupId=46570170-3ede-47a1-8c11-7670ce7e5aa4&tenantId=24fe244f-890e-46ef-be2f-a5202976b7a5) . This is useful to subscribe to to ensure everything is working correctly before you merge to master.
+
+### 🚀 Deploying
+
+In general, be prepared to synchronise your V5 deployment with your merge to **master** Branding Repo branch.
+
+As it only takes **1 minute** to build and deploy, you might need to take this into account with V5 work.
+
+#### Requirements
+
+- **V5 to have deployed its configs to V6 configuration-api for your environment**. This means V5 should be deployed to `QA` so its configs are set in `V6 dev`. This also means if you want to deploy a **master** branch of the Branding Repo, V5 would have had to deploy its configs in `Production` before we get to deploy our Branding Repo.
+  > **Ask V5 Backend why if it's not deployed.**
+- **KONG api keys exist for this CPID**. This should be an automated process [like this example](https://github.com/wiley/madgex-internal-kong/commit/f01ddef0479a72229a580d4c6eb33b942776035f), but if it does not exist for some reason this will fail a deployment.
+  > **Ask Systems why if it does not exist**
+
+#### Scenario - V5 not using Branding Repo, and V6 not live
+
+Merge branding repo working branch to master as soon as its ready. We assume V5 is in a `Production` so configs exist to enable deploying **master** branch. This would be `webtemp` domain if this is a new client.
+
+#### Scenario - V5 is using Branding Repo, but V6 is not live
+
+Merge branding repo working branch to master after it passes UAT/review and is ready for V5 `Production` to see new version.
+
+Once it is deployed to **master** you can view V6 version of the site by using the HTTP Header `x-madgex-v6` with a value of `true` and visiting a Jobseeker Site URL like `https://www.bigworkbag.com/newalert`
+
+#### Scenario - Both V5 is using Branding Repo, and V6 is already live
+
+Merge branding repo working branch to master after it passes UAT/review and is ready for V5 `Production` to see new version.
+
+There is no early preview for V6 unfortunately outside of the FERT development environment, and relying on V5's UAT for Header and Footer preview only (not V6 branding).
+
+### Enable Header Footer Podlet usage on V5
+
+By default V5 is not using Header or Footer from the Branding Repo.
+Create the config file in `<v5-site-resources>/Config/HeaderFooterPodlet.xml` [example](https://github.com/wiley/Madgex-BigWorkBag/blob/1216a7117c49bb93a2a2c8410bd670062443aaad/ResourceRoot/Sites/BigWorkBag.CustomResources/Config/HeaderFooterPodletConfig.xml)
+
+And set `JSEnabled` (Jobseeker Site) and/or `RSEnabled` (Recruiter Site) to `true` or `false`. By default these are `false`.
+
+```xml
+<?xml version="1.0" encoding="utf-8"?>
+<ArrayOfConfigSetting xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
+
+	<ConfigSetting>
+		<Key>JSEnabled</Key>
+		<Value>true</Value>
+	</ConfigSetting>
+
+	<ConfigSetting>
+		<Key>RSEnabled</Key>
+		<Value>true</Value>
+	</ConfigSetting>
+
+</ArrayOfConfigSetting>
+```
+
+> [!IMPORTANT]
+> Do not set `PodletApiUrl` (Not shown in example above), this causes conflicts with other environment configs (UAT).
+
+It is overall simpler to just create this base `HeaderFooterPodlet.xml` file so all environments are consistent, but you can also create environment-only configs if for example only want to enable it for Production `HeaderFooterPodlet.JobBoard-Production.xml`
+
+## V5 vs V6
+
+- V6 depends on the Branding Repo, a site can't exist without it
+- V5 does not load `madgex-design-system CSS`, V6 and FERT do
+  - Custom templates that do not use ShadowDOM can be affected by existing CSS on the page
+- V5 will fail to deploy if it cant access the header-footer-podlet
+- V6 only uses `production` **master** branch assets, there is no `dev`
+- V5 uses `production` **master** branch assets for `Staging` and `Production` environments
+- V5 uses `dev` **non-master** branch assets for `Local`, `QA` and `UAT`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@madgex/fert",
-  "version": "7.0.12",
+  "version": "7.0.13",
   "description": "Tool to help build the V6 branding",
   "bin": {
     "fert": "./bin/cli.js"
@@ -24,50 +24,49 @@
   "author": "Madgex",
   "license": "UNLICENSED",
   "dependencies": {
-    "@aws-sdk/client-cloudfront": "3.937.0",
-    "@aws-sdk/client-ssm": "3.936.0",
+    "@aws-sdk/client-cloudfront": "3.982.0",
+    "@aws-sdk/client-ssm": "3.982.0",
     "@hapi/hapi": "21.4.4",
     "@hapi/hoek": "11.0.7",
     "@hapi/inert": "7.1.0",
     "@hapi/vision": "7.0.3",
     "@hapipal/toys": "4.0.0",
     "@madgex/config-api-sdk": "1.13.1",
-    "@madgex/design-system": "13.0.4",
+    "@madgex/design-system": "13.2.1",
     "@private/header-footer-podlet-server": "github:wiley/madgex-header-footer-podlet",
     "axios": "1.13.2",
     "cac": "6.7.14",
     "chalk": "5.6.2",
-    "chokidar4": "npm:chokidar@4.0.3",
+    "chokidar5": "npm:chokidar@5.0.0",
     "debug": "4.4.3",
-    "dedent": "1.7.0",
+    "dedent": "1.7.1",
     "find-up-simple": "1.0.1",
-    "flat-cache": "6.1.18",
-    "form-data": "4.0.4",
-    "joi": "17.13.3",
-    "lodash": "4.17.21",
+    "flat-cache": "6.1.20",
+    "form-data": "4.0.5",
+    "joi": "18.0.2",
     "nunjucks": "3.2.4",
-    "open": "8.4.2",
+    "open": "11.0.0",
     "ora": "5.4.1",
     "prompts": "2.4.2",
-    "rimraf": "6.0.1",
-    "sass": "1.93.3",
+    "rimraf": "6.1.2",
+    "sass": "1.97.3",
     "simple-git": "3.30.0",
     "simple-update-notifier": "2.0.0",
     "uuid-validate": "0.0.3",
-    "vite": "7.1.12",
-    "vite-plugin-static-copy": "3.1.4"
+    "vite": "7.3.1",
+    "vite-plugin-static-copy": "3.2.0"
   },
   "devDependencies": {
-    "@commitlint/cli": "20.1.0",
-    "@commitlint/config-conventional": "20.0.0",
+    "@commitlint/cli": "20.4.1",
+    "@commitlint/config-conventional": "20.4.1",
     "@madgex/eslint-config-madgex": "2.3.0",
     "@madgex/prettier-config-madgex": "2.0.0",
-    "eslint": "9.39.1",
+    "eslint": "9.39.2",
     "husky": "9.1.7",
-    "lint-staged": "16.2.6",
-    "msw": "^2.12.3",
-    "prettier": "3.6.2",
-    "semantic-release": "24.2.9"
+    "lint-staged": "16.2.7",
+    "msw": "^2.12.8",
+    "prettier": "3.8.1",
+    "semantic-release": "25.0.3"
   },
   "lint-staged": {
     "*.{js,json}": [

package/server/plugins/hapi-vite.js

@@ -2,7 +2,7 @@
 import { glob } from 'node:fs/promises';
 import path from 'node:path';
 import { createServer } from 'vite';
-import chokidar from 'chokidar4';
+import chokidar from 'chokidar5';
 import * as Hoek from '@hapi/hoek';
 
 const internals = {};

package/server/templates/default.njk

@@ -1,4 +1,5 @@
 {% extends "furniture.njk" %}
+{% from 'icons/_macro.njk' import MdsIcon %}
 
 {% block main %}
     <ul class="mds-list mds-list--inline mds-list--pipe">
@@ -14,13 +15,20 @@
         <div class="mds-grid-col-12 mds-grid-col-lg-9 ">
         <div class="mds-surface">
             <div class="mds-surface__inner">
-            <h1>Page title</h1>
+            <h1>Frontend Rollout Tool</h1>
+                      
+            <h2>Documentation</h2>
+            <ul>
+                <li><a href="https://github.com/wiley/madgex-frontend-rollout-tool/blob/master/docs/README.md">Readme</a></li>
+            </ul>
+            
             <h2>Text</h2>
             <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas tempus tortor nulla, id viverra lacus maximus vel.
                 In tincidunt ultrices neque in maximus. Donec leo lectus, aliquet vel molestie lacinia, elementum vel arcu. Integer
                 iaculis diam non mattis eleifend. Curabitur et tempus felis. Vestibulum tempor nec libero id blandit. Duis fermentum
                 pulvinar eleifend. Vestibulum pellentesque mauris sed augue finibus, sit amet laoreet felis fermentum. Donec in dolor id
                 elit cursus pellentesque.</p>
+
             <p><a href="#">Link</a><p>
             <p><button class="mds-button">Button</button></p>
             </div>
@@ -28,10 +36,12 @@
         </div>
         <div class="mds-grid-col-12 mds-grid-col-lg-3">
         <div class="mds-branded-container mds-branded-container--1 mds-padding-b4 mds-padding-bottom-b5 mds-margin-bottom-b5">
+           {{ MdsIcon({ path:"/design-system/assets/icons.svg", iconName: 'email',classes: 'mds-icon--md  mds-margin-bottom-b2' }) }}
             <h2 class="mds-font-s2">Branded Container</h2>
             <p class="mds-margin-bottom-b4">Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
             <a href="#" draggable="false" class="mds-button mds-button--small">Lorem ipsum</a>
         </div>
         </div>
     </div>
+
 {% endblock %}