Pwa Laravel Package

Getting Started

Confirm the precondition before you type a command. bagisto/pwa is a Bagisto-specific module, not a general Laravel PWA toolkit. The v1.3.2 release is explicitly "compatible with v1.3.0" of Bagisto core, so the first day-one task is composer show bagisto/core in your store. If you are on Bagisto < 1.3.0, or on plain Laravel, stop — the value collapses and you should evaluate a generic PWA package instead.

Install, pinned to the tag, not a branch:

composer require bagisto/pwa:v1.3.2

Then the standard Bagisto/Laravel module path — register the service provider, publish assets, clear caches:

php artisan vendor:publish --provider="Webkul\PWA\Providers\PWAServiceProvider" --tag=public
php artisan vendor:publish --provider="Webkul\PWA\Providers\PWAServiceProvider" --tag=config
php artisan optimize:clear

Verify the exact provider namespace and tag names against the package source before scripting this into a deploy — the changelog does not document them and there are zero recorded dependents to copy from.

Where to look first, in this order:

1. The package's own composer.json — is the Bagisto core constraint actually enforced there, or only mentioned in the README? This single answer determines whether Composer protects you during future upgrades or you protect yourself with a pin.
2. The service provider — it tells you what is registered: routes, view namespaces, asset publishing, middleware. This is your real documentation.
3. The published config file — look for cache/offline/service-worker settings and any per-channel switches.
4. The published manifest and service-worker JS — this is where your cache-invalidation contract lives or dies.
5. The storefront blade overrides — where the mobile-first shell is applied to Bagisto's existing views.

First use case: get the install prompt and offline shell working on a single channel, then immediately test the thing that actually matters commercially — change a product price in admin and reload the installed PWA on a phone. If the old price is still there, you have found your real project before you have written any feature code.

Implementation Patterns

Treat the module as an additive theme layer, not an app stack. The package augments Bagisto's existing rendering path — same auth, same session, same deploy pipeline. That means your day-to-day customization should live in a small local module that depends on bagisto/pwa, overriding views, config, manifest, and the service worker. Never edit vendor/; v1.3.2 is a patch tag on a fast-moving release train and you will lose the edits.

Co-schedule upgrades with core. The module rides the Bagisto release train rather than versioning independently. Put PWA bumps inside your core-upgrade milestone, not on a parallel cadence — otherwise you pay for two regression windows to ship one user-facing change.

Build an observability probe around the module status check. v1.3.2 adds a status check, which converts the worst failure mode — storefront looks fine, PWA layer is silently disabled, users sit on a stale service worker — into a detectable state. But it only helps if you monitor it. Add a health endpoint or deploy smoke test that asserts the module is registered and the manifest is being served, and run it per channel in a multi-store setup.

Define a cache invalidation contract explicitly. Don't inherit the default and hope. A pattern that holds up:

• Hashed static assets → cache-first, long TTL.
• Category and PDP HTML → network-first (or stale-while-revalidate with a short TTL) so price and inventory changes land.
• Cache name versioning → derive the cache key from a deploy/build env var so every release orphans the old cache and forces a clean fetch.
• Deploy hook → on price or inventory bulk updates, bump the version rather than chasing individual URLs.

Write this down as a contract, because stale pricing is a commercial exposure, not a caching nuisance.

Wire Compare Products (new in v1.3.2) deliberately. It is a consideration-phase merchandising lever, so the product decision is nav entry vs. contextual from category listings. The engineering decision is whether comparison state is client-only or persisted server-side — and if server-side, whether it interacts with the cart, catalog cache, or price resolution. Confirm both before you surface it prominently.

Instrument analytics once, in the PWA shell. Standalone display mode and app-like navigation often break pageview tracking that assumes full page loads. Fire analytics on route change, not just on DOM ready, and compare event counts against your web channel before you trust the numbers.

Spike SEO early, with view-source. If critical catalog content renders client-side, that is a product-visible change to organic acquisition. Check view-source: and a crawler fetch, not the DevTools DOM, before you commit to turning this on for the primary storefront.

Gotchas and Tips

ProductRepository was removed in PR #165. Labelled "irrelevant," but any local override, decorator, plugin, or extension referencing that class breaks at load time. Grep your codebase for it before running the composer update. This is the single highest-probability integration failure in the release and the cheapest to check.

Do not trust the semver. v1.3.2 carries a patch number but ships a net-new user-facing surface (Compare Products, #196) plus a core compatibility bump. Classify it by diff in your change advisory, not by the version digit.

The changelog is an incomplete record. It jumps v1.2.0 → v1.3.2; v1.3.0 and v1.3.1 must be reconstructed from git history. "Fixed issue #198" (#199) carries no description, so its blast radius is unknowable from the notes. Diff v1.2.0...v1.3.2 before scoping the upgrade.

Three of six merged PRs came from first-time contributors — and two of those are the highest-impact PRs (Compare Products, module status check). Read those two diffs directly rather than trusting the summary.

Service workers are sticky in development. Always use incognito, and in DevTools → Application → Service Workers enable "Update on reload" and "Bypass for network" while iterating. chrome://serviceworker-internals is your unregister escape hatch when a bad cache wedges you. The service worker must be served from root scope with the correct MIME type and no long-lived cache header on the SW file itself — check your web server config, not just Laravel.

Config changes may not appear. Bagisto caches configuration; if you edit the published PWA config and nothing changes, run php artisan optimize:clear (and check Bagisto's own cache-clear path). View changes need the compiled-view cache cleared too.

Add a manual PWA QA checklist to the release runbook. Generic Laravel test suites don't cover service-worker registration, install prompts, offline fallback, or update flows. At minimum: install on Android and iOS Safari, toggle offline, change a price, force an update, verify the old cache is gone.

Budget internal ownership. Zero recorded dependents and a low overall score mean you are the early adopter absorbing the discovery cost, on community-maintained open source with no SLA. Pin the tag, vendor-fork if you need to patch, and assume you will read source rather than documentation for anything the changelog doesn't say.