Laravel Pwa Laravel Package

Technical Evaluation

Architecture fit. The package is a thin convenience layer, not a platform: it generates a static manifest.json and service worker into public/, exposes two Blade directives (@PwaHead, @RegisterServiceWorkerScript), a PWA facade for runtime manifest updates, and a logo-upload helper. It introduces no runtime services, queues, migrations, or middleware, so it does not alter the application's architecture. That is the right shape for what it does, but it also means the package's value is "saves ~150 lines and a config file" — a build-vs-buy decision a TPM should make explicitly rather than default into.

Integration feasibility. Low-effort: composer require, one command (erag:install-pwa), two directives in the layout. Claimed Laravel 8–13 support means it will not gate a framework upgrade. Compatibility with Livewire/Vue/React is structural rather than tested — the directives only emit HTML/JS, and there is a livewire-app config flag plus a v1.8.0 "Livewire app error fix," which signals that Livewire's SPA-style navigation is a known friction point rather than a solved one. Vue/React support is effectively "it works if your index HTML is server-rendered by Blade," which excludes SPA deployments using a separate frontend build.

Technical risk. The material risks are concentrated in three areas:

• Service worker behavior is undocumented and unowned. The README says nothing about caching strategy, precache manifests, cache versioning, or update propagation. A cache-first service worker without version bumps is the classic way to strand installed users on stale assets after deploy. This must be verified by reading the shipped sw.js, not the docs.
• Runtime writes to public/. The facade writes manifest.json at request time and processLogo() overwrites public/logo.png. This conflicts with immutable/read-only filesystems, ephemeral containers, and horizontally scaled deployments (write lands on one node, siblings drift). It is also a fixed, unconfigurable filename — a collision hazard for multi-brand or multi-tenant apps with an existing logo.png.
• Governance and license. License is reported as NOASSERTION while the README claims MIT; the discrepancy must be closed by legal before adoption. The package is single-maintainer with 0 dependents — no downstream field validation, no bus factor. Maturity signals are README and releases only; there is no evidence of a test suite or CI. The team would be the first real verifier.

Secondary risks: opinionated defaults likely to ship unedited (display: 'fullscreen' rather than standalone, app name "Laravel PWA", short name "LPT"); an unauthenticated-capable file-upload helper that must be reviewed for validation and route protection; and a debug console-logging toggle.

Key questions.

1. Is the emitted service worker cache-first, and does it carry a cache version derived from the deploy?
2. Are the manifest.json and logo.png writes required for our use case, or can we go read-only and commit the artifacts instead?
3. Does the license file resolve unambiguously to MIT under legal review?
4. What is the exit cost if the maintainer stops releasing? (Likely low — config, two directives, two static files — which materially reduces the risk in the previous answer.)
5. Do we have any deployment targets with read-only or multi-instance filesystems?

Integration Approach

Stack fit. Good fit for a monolith serving Blade-rendered HTML: Laravel 8–13, Livewire or server-rendered Vue/React islands. Poor fit for decoupled SPA frontends (Vite + Vue/React SPA with a token-auth API), where the directives never reach the rendered shell and PWA wiring belongs in the frontend build (vite-plugin-pwa), not in PHP.

Migration path. Treat this as additive with a deliberate exit hatch. Pin ^2.1 in composer.json and rely on the lockfile; do not float. Do not let PWA::update() and PWA::processLogo() spread beyond a single settings controller and service — wrap them behind an internal PwaSettings interface so the package is one adapter swap away from removal. Prefer committing generated manifest.json/sw.js and configuring via config/pwa.php + erag:update-manifest in CI, avoiding the runtime-write path entirely.

Compatibility checks. Confirm the Laravel version matrix against our actual constraint; confirm PHP version support; confirm the service worker is served from the app root so its scope covers the whole origin (a SW served from a subpath silently limits scope); confirm HTTPS termination at the edge still presents a secure context to the browser.

Sequencing.

1. Week 0 — audit (2–3 days): read sw.js and the manifest generator; legal clears the license; security reviews processLogo() validation and any published route.
2. Week 1 — spike (1–2 days): install in a staging app on our real layout, verify install prompt on Android Chrome and iOS Safari, verify offline page, verify a deploy updates cached assets. This is the go/no-go gate.
3. Week 2 — pilot: one low-traffic surface (marketing site, internal tool, or a secondary app) with committed artifacts and CI generation.
4. Week 3+ — decide: promote to the main product, or replace with ~150 lines of in-house manifest route + service worker we own. Given the exit cost is trivial, this fallback is credible and should be priced before committing.

Operational Impact

Maintenance. Low code surface, but maintenance is not zero: the package is pre-3.x, jumped v1→v2 within a year, and ships frequent small releases (v2.1.0 for iOS install prompts, v2.1.1 doc fixes). Budget a recurring dependency-review slot and expect to read diffs rather than trust release notes. Because we would be among the earliest adopters, we should assume we will find the bugs and upstream them.

Support. Effectively community-only: single maintainer, GitHub issues, no vendor SLA, no paid support. Internal ownership must be assigned — a named engineer responsible for the service worker and manifest — otherwise PWA breakage will be diagnosed by whoever notices the install prompt stopped appearing.

Scaling. Runtime cost is nil: static files served from public/, CDN-friendly. The scaling concern is deployment topology, not load — the write paths degrade under multi-instance and read-only filesystems. Committing artifacts and generating in CI removes this class of problem entirely and is the recommended posture.

Failure modes to instrument.

• Stale-asset lockout after deploy (cache-first SW, no version bump) — highest impact, hardest to detect because it only affects previously-installed clients.
• Silent manifest drift between nodes if runtime updates are used.
• logo.png overwrite clobbering an existing brand asset.
• Install prompt suppressed by missing icon sizes, wrong MIME type, or display mode not meeting browser install criteria.
• iOS-specific install behavior regressing on OS updates (already needed a patch in v2.1.0).
• File upload path: oversized/invalid uploads, or the endpoint exposed without auth. Mitigations: a synthetic check that fetches manifest.json and sw.js post-deploy and asserts a version marker; smoke-test the install prompt in a release checklist.

Ramp-up. Very shallow — an engineer can integrate in under an hour from the README. The ramp-up cost sits on the verification side: someone must understand service worker lifecycle and cache invalidation to operate this responsibly, and that knowledge is not in the package. If no one on the team owns that, budget for it before adoption.

Recommendation. Conditional adopt for Blade-rendered surfaces where PWA is a nice-to-have (installability, offline page), with committed artifacts and CI generation rather than runtime writes, contingent on the license clearing and the service worker audit passing. For a core product surface where PWA behavior is user-facing and revenue-relevant, favor owning a small in-house implementation — the dependency's convenience is modest relative to the verification and stewardship burden it transfers to us.