Importmap Laravel Laravel Package

Product Decisions This Supports

• Frontend build strategy: Decides whether a given Laravel surface ships as "no-build ESM + import maps" versus Vite/npm bundling. This is a per-surface call, not a whole-product one.
• Roadmap input for toolchain reduction: Removing Node/npm from CI, deploy images, and developer laptops cuts build minutes, dependency-update churn, and supply-chain surface. This package is the concrete enabler for that roadmap item.
• Build vs. buy: Replaces a bespoke asset-pinning script (sha384 hashing, manifest generation, cache busting) with a maintained MIT package. You are buying a pattern and a thin helper, not a platform — so budget for internal ownership.
• Feature scoping: Gives a defensible line for "does this feature need React/Vue?" If the answer is no, importmaps keep the surface in Blade + Stimulus/Alpine/vanilla ESM.
• Primary use cases: admin panels, internal tools, CRUD SaaS dashboards, content/marketing sites on Blade, agency and starter-kit templates, and legacy app modernization where a Vite migration is out of scope.
• Dependency and security governance: An explicit importmap.php manifest of pinned URLs with SRI hashes is an auditable dependency inventory — useful for CSP/SRI reviews and lightweight compliance evidence, in contrast to a transitive package-lock.json graph.
• Hiring and onboarding: Lowers the JS barrier for PHP-centric teams; backend developers can ship frontend changes without a Node toolchain.

When to Consider This Package

Adopt when:

• The app is mostly server-rendered Blade, with a modest JS surface (a handful of libraries, first-party modules in the low hundreds of KB).
• Browser targets are evergreen — import maps are baseline in modern browsers; there is no IE or old-Safari requirement.
• The team is PHP-first and Node/npm in CI is a measurable cost or a genuine skill gap.
• You want explicit, reviewable pins and integrity hashes rather than a lockfile plus transitive graph.
• Production serves over HTTP/2 or HTTP/3, so many small module requests are acceptable.
• You accept manual pinning and updating of vendor libraries, and are comfortable vendoring them or serving from a CDN whose availability you trust.
• You can live without HMR, code splitting, and tree-shaking.

Look elsewhere (Vite, or a real bundler) when:

• The product is an SPA, or JS is the product: React/Vue/Svelte, complex client state, client-side routing.
• You need TypeScript type-checking, JSX, or npm packages with deep transitive trees and Node-only build steps.
• You need HMR, per-route chunks, bundle-size budgets, or tree-shaking.
• CSS requirements exceed what Tailwind's standalone CLI handles.
• You require vendor SLAs or enterprise support — a ~150-star, single-primary-maintainer project carries bus-factor risk.
• You run a strict CSP with no third-party origins and no appetite to re-vendor and re-pin on every upstream release.

De-risking note: the two approaches coexist. Running Vite for the app shell and importmaps for admin surfaces is a legitimate transitional architecture and makes the decision reversible.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed Laravel package that lets us ship modern JavaScript without a Node build pipeline. The business case is cost and risk reduction, not new features: fewer CI minutes and container layers, a smaller third-party dependency surface, explicit version pins with integrity hashes for auditability, and a frontend workflow our PHP developers can own end to end. It fits admin tools, internal apps, and content surfaces well; it is not a fit for a customer-facing SPA. Recommendation: a bounded pilot on one internal surface with a documented exit path back to Vite. The principal risk is project maturity — one primary maintainer and roughly 150 GitHub stars — which we mitigate by treating this as adopting a documented browser standard with a thin helper, keeping every pin in version control, so switching costs stay low and reversible.

For engineering: Import maps are a browser standard, so this is not a proprietary runtime — it is a thin pinning and manifest layer. You get a versioned importmap.php manifest of pinned ESM URLs with SHA-384 SRI, artisan commands to pin and update, and Blade-level wiring. There is no transpile step, no bundle, and no node_modules; deploys are static assets plus a JSON manifest, and cache busting comes from content digests. The costs are real and should be accepted explicitly: no HMR, no tree-shaking or code splitting, a module waterfall on cold loads (fine over HTTP/2), and manual version management. Proposed guardrails: pilot scope limited to one surface, a written pin-review policy, and a CI check that the manifest is in sync with what is actually served.