14-Mar-2026 — Maps, Frontend and 3 more areas: 1 fix, 2 build changes and 3 CI updates #185

build 532 — commit 301839a

Summary

• keep the Explorer-style OS map path on the existing Leisure_27700 configuration
• tighten the proj4leaflet integration used by the frontend map tile service
• centralise projection code names behind shared constants instead of repeating raw EPSG:27700, EPSG:3857, and WGS84 strings
• align the server ESRI import paths with the same shared projection constants

Verification

• npm run test -- --include='projects/ngx-ramblers/src/app/services/maps/map-tiles.service.spec.ts'
• cd server && npm run build
• confirmed the staging deployment map display now renders correctly

frontend: upgrade Angular 21 and migrate tests to Vitest (#185)

Summary

• Upgrade the frontend workspace from Angular 20 to Angular 21 and move the unit-test pipeline from Karma/Jasmine to the Angular application builder with Vitest.
• Keep the local development flow working by aligning repo install behaviour with the current Angular 21 dependency graph.
• Remove the legacy Angular global scripts bundle and complete the remaining runtime fixes uncovered during local validation.

What changed

Angular and tooling

• Upgrade Angular core, CLI, CDK, compiler, language service, and angular-eslint to Angular 21 compatible versions.
• Move the app build to @angular/build:application, the dev server to @angular/build:dev-server, extract-i18n to @angular/build:extract-i18n, and unit tests to @angular/build:unit-test.
• Replace Karma/Jasmine bootstrap files with a shared Vitest setup at projects/ngx-ramblers/src/test-setup.ts and remove the obsolete karma.conf.js and src/test.ts files.
• Add type-fest because the Mermaid module type surface now requires it.

Test migration and spec cleanup

• Refactor the frontend spec suite to run under Vitest, including explicit vi imports where editor resolution was unreliable.
• Add explicit expect imports in the async matcher specs that use await expect(...).resolves(...) so editor navigation and type resolution stay stable under Vitest.
• Replace the remaining legacy HttpClient and HttpHandler test wiring in meetup-service.spec.ts with Angular 21 HTTP testing providers and lightweight service stubs, removing the this.handler.handle is not a function stderr noise.
• Clean up schematic fallout in service and utility specs so matcher usage, spies, async handling, and local stubs all work consistently under Vitest.
• Preserve the existing test coverage surface rather than reducing scope for the migration.

Application compatibility

• Replace the Angular global scripts bundle in angular.json with module-based usage.
• Wire Mermaid through the ESM module path in app.module.ts, assign it to globalThis.mermaid for ngx-markdown, and register the custom and Iconify logo packs on the same instance.
• Add a project .npmrc with legacy-peer-deps=true so ngx-cli local dev and other repo installs continue to work while ng2-file-upload still advertises Angular 20 peers.
• Harden the walk-list Leaflet popup auto-open flow so delayed timers are cancelled during rebuilds and teardown, preventing stale popup work from hitting detached marker DOM.

Developer-facing behaviour

• ng serve --project ngx-ramblers --configuration development --verbose no longer emits the earlier angular:script/global:scripts directory read failure.
• Local markdown rendering with the mermaid attribute no longer throws the ngx-markdown Mermaid runtime error after startup.
• ngx-cli local dev <env> no longer depends on a manual --legacy-peer-deps install workaround.
• Vitest is now the default frontend unit-test runner for this workspace.
• The Meetup service spec no longer emits the old this.handler.handle is not a function HTTP test setup noise.

Verification

• npm run test -> 46 passed, 697 passed
• Targeted migrated-spec slice -> 8 passed, 118 passed
• Targeted async matcher specs -> 2 passed, 8 passed
• npm run test -- --include='projects/ngx-ramblers/src/app/services/meetup-service.spec.ts' -> 1 passed, 2 passed
• ng build --project ngx-ramblers --configuration development --verbose -> passed and removed the legacy global-scripts startup debug noise
• npm install --dry-run -> passed with project-level legacy peer dependency resolution enabled

Known limitations

• npm run build still fails on the existing initial bundle budget in angular.json.
• The current initial bundle is lower than the static Mermaid import attempt, but it still exceeds the configured 8 MB error budget.
• Existing Sass deprecation warnings and CommonJS warnings remain and are not resolved in this commit.

How to use the new setup

• Run frontend unit tests with npm run test.
• Run local development with ngx-cli local dev <environment> or ./bin/ngx-cli local dev <environment>.
• Use the Angular 21 application builder flow for development and build diagnostics going forward; the older Karma-specific setup is no longer part of the frontend workspace.

runtime: align repo with Node 24 LTS (#185)

Runtime baseline

Upgrade the repository baseline from Node 22.19.0 / npm 10.9.3 to Node 24.14.0 / npm 11.9.0.

Tooling and infrastructure

Align .nvmrc, package engine declarations, Docker, and GitHub Actions workflow runtime settings with the Node 24 baseline. Opt workflow JavaScript actions into Node 24 and keep the deploy matrix at max-parallel 6 with npm fetch retries in deploy installs.

Compatibility updates

Upgrade Serenity, WebdriverIO, and npm-failsafe dependencies so local install, build, and test flows run on Node 24 without unsupported engine warnings.

Documentation

Update README, AGENTS guidance, release-notes docs, and codebase-evolution-stats.html so the documented platform baseline matches the actual runtime target.

Ramblers export fix

Use the configured public group URL for Ramblers CSV website links so local development exports do not publish localhost URLs into Walks Manager.

Verification

Validated locally on Node 24 with lint, frontend tests, server tests, targeted URL service coverage, and production build.

Follow-on

Leave Angular 21 as separate follow-on work under issue #185 so framework changes are isolated from the runtime uplift.

workflows: align Chrome and action runtimes (#185)

Workflow runtime alignment

Upgrade GitHub Actions checkout and setup-node steps to current Node 24-compatible versions, replace the remaining Docker and Fly JavaScript actions with shell-based equivalents, and keep the workflow behaviour unchanged.

Chrome version consistency

Read CHROME_VERSION from injected configuration for the build workflow, use the same value for headless test setup and Docker image builds, and remove the hard-coded server-side setup literals that could drift from deployed environments.

Verification

Validated workflow YAML parsing, server TypeScript compilation, and diff hygiene locally.

workflows: add npm fetch retries to GitHub installs

What changed

• Added npm fetch retry settings to root and server dependency installs in the test and deploy jobs.
• Increased retry backoff for package download failures seen on GitHub runners.

Why

• Recent runs failed with transient ECONNRESET errors during npm ci.
• The workflow was otherwise healthy, with lint and test stages passing when installs completed.

Behaviour

• This does not change build, test, or deployment logic.
• It only makes GitHub Actions installs more resilient to temporary network issues.

deploy: make full deploy explicit after successful build

What changed

• Removed commit-message-driven all-environments deployment.
• Updated the push helper to wait for the main build workflow for the pushed commit.
• Triggered the all-environments deploy workflow only after that build succeeds.
• Passed the successful build run number as the deploy image tag for traceability.

How to use

• Use a normal commit message with no deployment marker.
• For staging only, push normally.
• For a full deploy, run the explicit push flow so the agent or terminal waits for the build and then dispatches the all-environments workflow.
• The follow-up deploy uses the exact successful build run number as image_tag.

Behaviour

• Staging still deploys first through the main build workflow.
• All-environments deploy now requires an explicit action instead of hidden commit-message behaviour.