📅 End-of-Life Strategy — Riksdagsmonitor

🔄 Technology Lifecycle Management for Static Intelligence Platform
📦 Node.js 26 Active • ⏭️ Node.js 26 LTS Promotion October 2026 • ⚡ Future-Ready Architecture

📋 Document Owner: CEO | 📄 Version: 1.5 | 📅 Last Updated: 2026-05-28 (UTC)
🔄 Review Cycle: Annual | ⏰ Next Review: 2027-05-28
🏢 Owner: Hack23 AB (Org.nr 5595347807) | 🏷️ Classification: Public

Overview

Riksdagsmonitor is a static HTML5/CSS3 website deployed to AWS CloudFront + S3 (primary) and GitHub Pages (disaster recovery), built with Vite, tested with Vitest and Cypress, and powered by Node.js 26. The platform provides Swedish Parliament transparency through interactive Chart.js and D3.js visualisations across 14 languages.

⚡ Upgrade Note (July 2026): The toolchain migration to TypeScript 7 has started. The project now runs the TypeScript 6 compatibility package (typescript) side-by-side with a TypeScript 7 RC toolchain (typescript-7) so the build can validate the next compiler without breaking existing workflows. Node.js 26 remains the current runtime and will be promoted to LTS in October 2026; a Node.js 27 nightly compatibility CI job (continue-on-error: true) tracks the next-generation release. See the Node.js Migration Roadmap for the full plan.

This document defines the technology lifecycle management strategy — covering the current stack, Node.js release schedule evolution, dependency EOL timelines, and migration plans — to ensure stability, compatibility, and security throughout the project's operational life.

This strategy should be read alongside the Business Continuity Plan, Financial Security Plan, and Architecture Documentation for full technical and business context.

EOL Objective

Primary Goal: Maintain Riksdagsmonitor on a supported, secure technology stack by proactively tracking dependency lifecycles and planning migrations before components reach end-of-life.

Key Principles:

• Upgrade to new Node.js Current versions promptly; LTS promotion happens in-place (no second migration needed)
• Keep build tooling (Vite, Vitest, TypeScript) on latest stable versions
• Maintain zero known critical/high vulnerabilities via automated scanning
• Plan major migrations 12 months before dependency EOL dates
• Ensure the static output (HTML/CSS/JS) remains browser-compatible for 5+ years

🔄 Node.js Release Schedule Evolution

Why the Schedule Is Changing

The current Node.js release schedule is 10 years old, created during the io.js merger. A decade of usage data now shows:

• Odd-numbered releases see minimal adoption — most users wait for Long-Term Support
• The odd/even distinction confuses newcomers and many organisations skip odd releases entirely
• Volunteer sustainability — Node.js is maintained primarily by volunteers; managing security releases across four or five active release lines has become difficult to sustain, as each additional line increases backporting complexity

By reducing concurrent release lines, the project can focus on better supporting the releases people actually use while making the schedule more predictable for enterprises.

New Node.js Release Model (Effective October 2026)

Starting with Node.js 27.x, the Node.js project is moving from two major releases per year to one (see nodejs/Release#1113 for full background). Key changes:

New Release Lifecycle Phases

For users who already only upgrade to LTS versions, little changes beyond version numbering. LTS support windows remain similar, and now every release becomes LTS.

Impact on Riksdagsmonitor

• Simplified upgrade planning: Every Node.js release becomes LTS, eliminating the need to skip odd-numbered versions
• Annual upgrade cadence: Plan one major Node.js upgrade per year (April release, adopt after October LTS promotion)
• Alpha testing in CI: Integrate Node.js alpha releases into the CI matrix to catch compatibility issues early — this is critical since alpha is the only window to report bugs before they affect LTS users
• Reduced concurrent support lines: Fewer active Node.js versions means clearer migration targets and less upgrade pressure
• Library author responsibility: As a consumer of npm packages, we benefit when library authors test against alpha versions; we should also test our own build tooling compatibility early

CI Alpha Testing Strategy

To proactively catch Node.js compatibility issues, Riksdagsmonitor will adopt the following alpha testing approach:

This allows early detection of breaking changes in Node.js alpha while keeping production deployments stable on LTS.

📦 Current Technology Stack & EOL Timeline

Runtime & Build Environment

Testing Framework

Runtime Dependencies (Browser)

Development & Quality Tools

TypeScript Lifecycle

Note: TypeScript 6.0 is a major release with breaking changes including deprecated baseUrl option (still functional, silenced via ignoreDeprecations: "6.0"), stricter module resolution in bundler mode, and removal of implicit global namespace. The project uses @typescript-eslint 8.60.0 which supports typescript >=4.8.4 <6.1.0.

TypeScript Upgrade Policy

1. Upgrade to new patch versions immediately — bug fixes only, no breaking changes.
2. Upgrade to new minor versions within 2 weeks — validate tsc --noEmit, ESLint, and all tests pass.
3. Upgrade to new major versions within 1 month — major versions may require code changes and @typescript-eslint compatibility updates.
4. Never use TypeScript versions unsupported by @typescript-eslint — this would disable type-aware linting.

TypeScript Upgrade Triggers

🗓️ Node.js Migration Roadmap

✅ Completed: Node.js 24 LTS

✅ Current: Node.js 26 (Last Old-Model Release — LTS)

Node.js 26 is the last release under the old two-per-year schedule. It releases as "Current" in April 2026 and will be promoted to LTS in October 2026 — no additional migration will be needed at that point, as the project will already be on Node.js 26.

Strategy: Stay on Node.js 26 from Current through LTS in-place — no additional upgrade step required at October 2026 LTS promotion.

Completed upgrade checklist (for Node.js 26):

• [x] Validate TypeScript native type-stripping (process.features.typescript === "strip") still works
• [x] Confirm all 43+ workflows pass on Node.js 26 (blocking CI jobs)
• [x] Verify GitHub Actions ubuntu-26.04 runners include Node.js 26
• [x] Update all node-version: '25' → '26' across all workflow YAML and markdown files
• [x] Update package.json engines.node from >=25 to >=26
• [x] Update .nvmrc from 25 to 26
• [x] Update skills documentation (./github/skills/**SKILL.md) code examples
• [x] Update documentation (End-of-Life-Strategy.md, WORKFLOWS.md, FUTURE_WORKFLOWS.md, README.md, TESTING.md)
• [x] Add Node.js 27 nightly CI compatibility job (continue-on-error: true)

Future: Node.js 27 LTS (New Schedule)

Node.js 27 is the first release under the new one-per-year schedule where every release becomes LTS.

Future: Node.js 28 LTS (New Schedule)

Long-Term Node.js Upgrade Calendar

gantt
    title Node.js Lifecycle & Riksdagsmonitor Migration Plan
    dateFormat YYYY-MM
    axisFormat %Y-%m

    section Node.js 24 (completed)
    Active LTS           :done, n24lts, 2025-10, 2026-03
    Migration Off 24     :done, m24, 2026-03, 2026-03

    section Node.js 25 (interim — completed)
    Current (interim)    :done, n25curr, 2025-10, 2026-04
    Riksdagsmonitor on 25:done, rm25, 2026-03, 2026-04

    section Node.js 26 (last old-model — LTS)
    Current              :n26curr, 2026-04, 2026-10
    Active LTS           :n26lts, 2026-10, 2027-10
    Maintenance          :n26maint, 2027-10, 2029-04
    Riksdagsmonitor on 26:active, rm26, 2026-04, 2027-10

    section Node.js 27 (new model — first annual LTS)
    Alpha (27.0.0-alpha.x):n27alpha, 2026-10, 2027-04
    Current               :n27curr, 2027-04, 2027-10
    LTS                   :n27lts, 2027-10, 2030-04
    Riksdagsmonitor on 27 :rm27, 2027-10, 2030-04

    section Node.js 28 (new model)
    Alpha (28.0.0-alpha.x):n28alpha, 2027-10, 2028-04
    Current               :n28curr, 2028-04, 2028-10
    LTS                   :n28lts, 2028-10, 2031-04
    Riksdagsmonitor on 28 :rm28, 2028-10, 2031-04
Copy

🔧 Ongoing Maintenance Strategy

Dependency Update Policy

Automated Security Monitoring

• Dependabot: Automated dependency vulnerability alerts and PRs
• CodeQL: Static analysis for JavaScript/TypeScript security issues
• GitHub Secret Scanning: Prevent credential leaks
• npm audit: Integrated into CI pipeline
• knip: Dead code and unused dependency detection

Browser Compatibility Strategy

Riksdagsmonitor outputs static HTML5, CSS3, and ES2020+ JavaScript. Browser support targets:

Vite Build Target: The Vite build configuration ensures output is compatible with modern browsers. The static output continues to function independently of the Node.js build tooling version.

CI/CD Pipeline Maintenance

📊 Risk Assessment

Technology Risk Matrix

Migration Complexity Assessment

🏁 Final EOL Condition

Riksdagsmonitor is a continuously maintained platform with no planned end-of-life. However, the project would enter EOL status if:

1. All maintainers cease activity and no successors are appointed
2. Core dependencies (Node.js, Vite, Chart.js, D3.js) all simultaneously reach EOL with no migration path
3. Browser standards fundamentally change, making the static HTML/CSS/JS output non-functional
4. The Riksdag (Swedish Parliament) ceases to exist or provide public data

In any EOL scenario:

• The static website will remain accessible on GitHub Pages indefinitely (read-only)
• All source code will remain available under Apache 2.0 license
• Data archives will be preserved in the repository
• A final release will be tagged with EOL notice

🔐 ISMS Policy Governance

The ongoing maintenance strategy aligns with Hack23 AB's ISMS-PUBLIC framework to ensure systematic security management throughout the platform lifecycle.

Maintenance Activities by ISMS Policy

Security Assurance:

• ✅ All dependency updates security-vetted through WORKFLOWS.md automated scanning
• ✅ Version compatibility tested before production deployment
• ✅ Security patches prioritised per Vulnerability Management policy
• ✅ EOL components tracked in Asset Register

📚 Related Documents

🏗️ Architecture & Planning

• 🏛️ Architecture — Current system architecture (C4 models)
• 🚀 Future Architecture — Long-term architectural vision
• 🧠 Mindmap — System conceptual relationships
• 📋 README — Project overview and quick links

🛡️ Security & Compliance

• 🛡️ Security Architecture — Current security implementation
• 🎯 Threat Model — STRIDE risk analysis
• 💰 Financial Security Plan — Cost analysis and security investment
• 📋 CRA Assessment — EU Cyber Resilience Act compliance
• 🔒 Security Policy — Vulnerability disclosure and management

🔄 Operations & Lifecycle

• 📋 BCP Plan — Business continuity and disaster recovery
• 🚀 Release Process — Release procedures with attestations
• 🔄 CI/CD Workflows — Security-hardened CI/CD pipelines
• 🔮 Future Workflows — Enhanced CI/CD roadmap

🔐 ISMS Policies

• 🔐 Information Security Policy — Overall security governance
• 🔍 Vulnerability Management — Security testing and remediation
• 📝 Change Management — Risk-controlled change processes
• 🏷️ Classification Framework — Business impact and risk assessment
• 🛡️ Secure Development Policy — DevSecOps requirements

📋 Document Control:
✅ Approved by: James Pether Sörling, CEO
📤 Distribution: Public
🏷️ Classification:
📅 Effective Date: 2026-05-28
⏰ Next Review: 2027-05-28
🎯 Framework Compliance:

🌐 IMF Cached Datasets — End-of-Life Preservation

Effective: 2026-04-24 · Authoritative hub: analysis/imf/README.md · analysis/imf/agentic-integration.md · analysis/imf/indicators-inventory.json · analysis/imf/data-dictionary.md · .github/aw/ECONOMIC_DATA_CONTRACT.md

IMF data preservation at platform sunset

IMF licence at end-of-life

The IMF data licence (attribution required, redistribution permitted) survives platform sunset. Archived IMF-cached data may be redistributed by successor projects provided the IMF attribution remains intact.

Successor-project handoff

Future maintainers inheriting Riksdagsmonitor receive:

1. The vintage-tagged IMF cache (full historical depth at sunset moment)
2. The scripts/imf-*.ts runtime (reusable in any TypeScript context)
3. The IMF integration playbook (agentic-integration.md)
4. The IMF threat model (THREAT_MODEL.md §IMF + FUTURE_THREAT_MODEL.md §IMF)

This enables a successor to either continue IMF integration immediately or migrate to a different economic-data provider (with full provenance for the data they inherit).

Canonical rule. Every economic claim in a Riksdagsmonitor article cites an IMF dataflow first; World Bank citations are reserved for governance, environment and social residue (the classes IMF does not publish). SCB is the Swedish-specific ground truth layer. See ECONOMIC_DATA_CONTRACT.md v2.1 for the banned-phrase list and vintage discipline (>6 mo → annotation).

🔗 Hack23 Ecosystem

🗳️ Empower citizens · 🔍 Strengthen democratic accountability · 🕵️ Illuminate the political process

_{© 2008–2026 Hack23 AB (Org.nr 559534-7807) · Maintainer: James Pether Sörling, CISSP CISM}