Blast Laravel Package

Product Decisions This Supports

• Design-system / component-library investment: Blast is the bridge that lets a Laravel Blade component library be developed and reviewed in Storybook. If a design system is on the roadmap, this package is what makes "isolated component development" a credible proposal for a Blade stack rather than a rewrite to Vue/React.
• Build vs. buy on internal tooling: The alternative is hand-rolling a Blade-to-Storybook harness (story generation, prop/knob mapping, asset wiring). v1.11.0 reinforces that the maintenance burden sits with upstream — a small, active contributor base is shipping features and framework compatibility — so the default should be adopt, not build, unless requirements are unusual.
• Framework upgrade planning: The Laravel 12.x compatibility PR removes Blast as a blocker in a Laravel upgrade. This is a direct input to sequencing an upgrade epic — front-end tooling no longer needs to be carved out as a separate risk item.
• Toolchain consolidation: The new custom Storybook version setting lets a team pin the Storybook release Blast uses. For organizations that already run Storybook for a Vue/React/admin surface, this materially lowers the friction of a second Storybook instance and reduces "two versions, two configs, two upgrade tracks" objections from platform engineering.
• Engineering hygiene / deprecation backlog: Fixes for PHP 8.2+ dynamic-property deprecation warnings reduce noise in CI and keep the package off the "abandoned or lagging" list during technical-debt reviews.
• Use cases to validate against: Blade component documentation sites, visual regression coverage for a marketing/CMS front end, and stakeholder review of components without spinning up full application pages.

When to Consider This Package

Adopt when most of the following hold:

• The product's front end is server-rendered Blade (or Blade-dominant), with a component library or a design system that has, or will have, more than a handful of reusable components.
• The team already uses Storybook, or has committed to it, and wants one review surface across stacks.
• Node/JS tooling is acceptable in the build pipeline — Blast does not remove the Node dependency, it only organizes it.
• You are on a supported Laravel version (12.x compatibility now confirmed; earlier majors per package docs) and PHP 8.2+, where the deprecation fixes in this release matter.
• Component review is currently a bottleneck: designers and PMs cannot see components without a full environment, or QA lacks a stable visual reference.

Look elsewhere — or defer — when:

• The front end is Inertia + Vue/React or a separate SPA; native Storybook already covers it and Blast adds a redundant layer.
• Components are heavily stateful or interactive (complex Livewire flows, multi-step forms); Storybook's value drops and the story surface becomes a maintenance tax.
• There is no component library and no near-term plan for one — the setup cost is not repaid.
• The organization cannot own a JS toolchain in CI for the Laravel repo, or security policy forbids adding a second Storybook deployment.
• You need production rendering guarantees; this is a development/documentation tool, not a runtime dependency, and should be scoped accordingly (dev-only, not a production deploy artifact).

Risk notes for the adoption case: the project is community-maintained by a digital agency, so treat it as a dependency with a modest bus factor — budget a spike to confirm it handles your component patterns (slots, nested components, asset pipelines) before committing it to a design-system roadmap.

How to Pitch It (Stakeholders)

For executives (one paragraph): Blast is a small open-source Laravel package that lets our Blade components be built and reviewed in Storybook — the same industry-standard component catalogue used on JavaScript projects. The practical effect is a shareable component library that designers, QA, and product can review without a running application, which reduces rework and review latency on UI work. The 1.11.0 release is a maintenance and compatibility release: it confirms support for Laravel 12 (so it will not block a framework upgrade), lets us pin the Storybook version to match tooling we already run, and clears PHP deprecation warnings. Cost is engineering setup time, not licence fees; the main risk is that it is a community-maintained project, which we mitigate by keeping it a development-only dependency.

For engineering (the ask): Adopt Blast as a dev-only dependency for the Blade component library; pin the Storybook version via the new 1.11.0 setting to align with our existing Storybook instance; confirm Laravel 12 and PHP 8.2+ in CI. Spike first against our trickiest components (slots, nested components, asset compilation) and agree an exit plan given the project's single-maintainer risk profile.