- What is anthonyedmonds/govuk-laravel and what problem does it solve?
- It is a presentation-layer Composer package that wraps the GOV.UK Design System (govuk-frontend HTML, CSS and JS) in Laravel Blade components, layouts and form helpers. Instead of hand-writing GOV.UK markup and wiring error classes yourself, you render components and let the package produce compliant, consistent output. It is aimed at server-rendered Laravel services that need to meet the GDS Service Standard or mirror GOV.UK patterns. It adds no domain logic, persistence or queued work, so it sits alongside your application architecture rather than inside it.
- How do I install govuk-laravel in a Laravel application?
- Install it with Composer using composer require anthonyedmonds/govuk-laravel; the package supports standard Laravel auto-discovery, so no manual service provider registration is normally needed. You then publish the package's views and front-end assets so the GOV.UK CSS and JavaScript are served from your application. Published views also become the place where you override markup. Check the README for the exact publish tags and any required asset setup steps.
- Which Laravel and PHP versions does govuk-laravel support?
- The package targets Laravel applications that use Blade and server-rendered forms, but you should confirm the exact PHP and Laravel constraints in its composer.json before upgrading. Verify those constraints against your runtime rather than assuming parity with your current Laravel version. Because the package tracks upstream govuk-frontend releases, support windows can shift between minors. It is also worth checking whether the supported matrix is covered by CI in the repository.
- How do I customise or override the GOV.UK Blade component markup?
- The package's views are publishable, so you can copy them into your application and edit the Blade templates directly. That is the intended extension point for bespoke layouts, extra classes or organisation-specific content. Be aware that published overrides are the most common source of silent divergence after an upgrade, because upstream component changes will not reach your edited copies. Keep a diff of your overrides against the vendor versions so you can review them at each release.
- Does govuk-laravel work with Laravel's form validation and old input?
- Yes. The form helpers are designed to complement Laravel's validation, old() input repopulation and error bags rather than replace them, mapping errors onto GOV.UK error messages and error summaries. You keep using standard Laravel validation rules and Form Requests, and the components handle the presentation of the resulting messages and field-level error states. This is why the package fits naturally into conventional server-rendered Laravel form workflows.
- What changed in govuk-laravel 8.6.0?
- Version 8.6.0 is a minor bump from 8.5.0 containing two changes: a feature referencing GOVUK 65 and a back to top component or pattern. Nothing in the release notes signals a breaking change, a configuration change or a minimum-version bump. The notes are very terse, so treat GOVUK 65 as unresolved until you confirm whether it refers to an internal roadmap item, an upstream govuk-frontend issue or a component-parity ticket. Confirm the required govuk-frontend version and whether the back to top pattern is upstream or package-local before adopting it.
- Do I need to republish views or assets after upgrading govuk-laravel?
- The 8.6.0 notes do not state whether republishing is required, so verify it yourself rather than assuming a drop-in upgrade. The safe process is to branch, run composer update, then diff the vendor views and assets against your published copies and re-publish selectively. After that, confirm the GOV.UK JavaScript still initialises, for example that GOVUKFrontend.initAll() runs, and re-run your test suite. If you have customised published views, review any component signature, slot or config key changes before merging.
- Is govuk-laravel accessible and compliant with WCAG 2.2 AA?
- Accessibility comes largely from the underlying GOV.UK Design System, which is built and maintained against government accessibility standards, and the package's job is to render that markup faithfully. That inheritance is only as good as your own content, headings, labels and error handling. The newer back to top component deserves particular scrutiny: if it is a package-local implementation rather than an upstream component, check its provenance, content guidance and keyboard behaviour. Test key journeys with axe or pa11y and with assistive technology before releasing.
- Is govuk-laravel a good fit for an API-first or single-page application?
- No. It is a presentation-layer package for server-rendered Blade views, so it adds little value in an API-first, SPA or mobile-backend product where the front end is not Laravel-rendered. It is also a poor fit where the brand is not GOV.UK, since the visual language is tightly defined. The right shape is a Laravel service in UK public sector, local authority, NHS-adjacent or regulated contexts that must follow GOV.UK patterns.
- What are the maintenance risks of using govuk-laravel, and what are the alternatives?
- The package is effectively single-maintainer, which is the dominant long-term risk, and its compatibility is coupled to the upstream govuk-frontend version, so upstream deprecations surface here with a lag. The mitigation is that it is a thin wrapper: you could fork it or vendor the components if maintenance stalled. Alternatives include using govuk-frontend directly with hand-written Blade partials, or adopting a different Laravel UI kit entirely if GOV.UK styling is not a requirement. Weigh the fork cost against the effort of maintaining GOV.UK markup yourself.