Govuk Laravel Laravel Package

Product Decisions This Supports

• Build vs buy for UK public-sector services: govuk-laravel wraps the GOV.UK Design System as Blade components. Adopting it converts a bespoke front-end build (Nunjucks templates, macro porting, style overrides) into a dependency — a significant scope reduction for any Laravel service that must meet the GDS Service Standard and pass a service assessment.
• Service Standard / accessibility compliance: Components track upstream GOV.UK Frontend, so WCAG 2.2 AA behaviour, focus states and error-message patterns arrive pre-validated rather than being re-derived per project. This lowers the assurance burden at accessibility audit and assessment panels.
• Roadmap sequencing — 8.6.0 and 8.7.0: 8.6.0 delivered an upstream sync to the GOV.UK 6.5 baseline plus a Back to top component. 8.7.0 is a feature release introducing mail support (single PR, "Feature/mail"). Both are additive and non-breaking on the evidence available, so upgrades can be slotted into routine maintenance rather than a dedicated hardening sprint.
• New surface area: transactional email and notifications. The mail feature extends design-system consistency beyond the browser into outbound email. If it provides reusable, GOV.UK-styled mail templates/layouts, this removes a recurring bespoke build — every service typically hand-rolls its own notification emails, and those are rarely reviewed against the same accessibility or content standards as the web UI. This is the most strategically interesting part of 8.7.0 and worth a scoping spike before committing.
• Caveat on release quality signals: the 8.7.0 changelog is a single PR title with no description, no migration notes and no documented component list. That is not a red flag by itself, but it means scope must be established from the diff or the docs, not the release notes. Treat "mail" as unverified capability until confirmed.
• Design-system drift as a tracked risk: Because component coverage is versioned against upstream, "we are N releases behind GOV.UK Frontend" becomes a measurable roadmap metric rather than an unknown. Useful for quarterly platform-health reporting.
• Use cases that fit: citizen-facing transactional services, case-working back offices, internal admin tooling built by in-house teams, notification-heavy services (now including the email channel), and any service where "looks like gov.uk" is a procurement or trust expectation rather than a design preference.
• Use cases that do not fit: brand-led commercial products, design systems already standardised elsewhere, or services outside the UK public sector where the GOV.UK visual language is a liability rather than an asset.

When to Consider This Package

Adopt when most of the following hold:

• You are building a Laravel service that must align with the GOV.UK Design System, and the alternative is porting Nunjucks macros by hand.
• Your team is PHP/Blade-fluent and would rather consume components than maintain a parallel front-end toolchain.
• You need auditable accessibility and error-handling patterns without commissioning bespoke work.
• You send transactional email and want those templates to derive from the same design system as the web UI (subject to verifying what 8.7.0's mail feature actually provides).
• You can absorb a dependency whose release cadence follows an external design system you do not control.

Look elsewhere when:

• Stack mismatch: the project is not Laravel, or the front end is a decoupled SPA/API where server-rendered Blade components add little.
• Design-system lock-in is unacceptable: adopting GOV.UK as the visual language is a product-positioning decision, not just a technical one.
• You need components not yet covered upstream: coverage is a moving target — verify the specific components on your critical path exist before committing. The same applies to the new mail feature: confirm it covers your template needs (layout, personalisation, branding, plain-text fallback) rather than assuming it does.
• Version-pinning constraints: if your platform standardises on an older GOV.UK Frontend baseline for audit reasons, an upstream-syncing package can force upgrade churn. Check the release notes for each bump.
• Very small surface area: for a two-page internal tool, the dependency and its upgrade obligations may outweigh the benefit.
• You need documented, mature features only: 8.7.0's notes give no migration guidance or API description. If your governance requires documented change records, wait for the docs to catch up or get scope confirmed in writing.

How to Pitch It (Stakeholders)

For executives: This is a Laravel package that supplies ready-made, government-standard UI components, so our team assembles pages from vetted building blocks instead of rebuilding them. That shortens delivery, reduces the risk of failing an accessibility or service assessment, and gives us a defensible "we use the standard" answer in assurance reviews. The latest release, 8.7.0, adds email/mail support — potentially letting us standardise notification emails on the same audited building blocks instead of one-off templates per service. It follows 8.6.0, which brought us to the current GOV.UK baseline and added a Back to top component. Both are routine, non-breaking updates; the mail feature needs a short scoping check before we rely on it.

For engineering: 8.6.0 was an upstream sync to the GOV.UK 6.5 baseline plus a new Back to top component. 8.7.0 is a feature release landing mail support via a single PR (#156), with no breaking changes signalled and no migration notes. Treat both as low-risk minor bumps, but for 8.7.0 do the diligence the changelog doesn't: read the diff to see whether it adds opt-in mail views/components or alters existing mail configuration, check for new publishable assets or config keys, and render the templates across major clients (including plain-text fallback and dark mode). Retire any hand-rolled Back to top pattern in favour of the package component, and consolidate bespoke notification emails onto the mail feature only after that check. Log both upgrades so our "releases behind upstream" metric stays visible.

Recommendation: proceed with the 8.6.0 → 8.7.0 upgrade as routine maintenance; no dedicated workstream required. Run a short (1–2 day) spike on the mail feature and pilot it in one service before making it the standard for outbound email. Reassess if a future release introduces breaking changes, lags the upstream baseline by more than one minor version, or if the mail feature ships without documentation.