Fireworks Laravel Package

Product Decisions This Supports

• Feature scoping for workflow and state machines. Attribute-level events (e.g., "fire when status moves to published") are the primitive behind publishing workflows, approval chains, and lifecycle transitions. This package is a cheap way to prototype whether per-field hooks are worth productizing before committing to a workflow engine.
• Build vs. buy on the event layer. The package is a thin trait over Laravel's native model events, checking dirty/original attributes. That makes the build-vs-buy answer mostly "build": a ~50-line trait or a handful of wasChanged() checks inside an Observer replicates it with zero third-party surface area.
• Audit trail and compliance roadmap. "Who changed what field, and what happened as a result" is a recurring requirement for enterprise tiers. Field-level events are the trigger point for audit logging, without logging every updated event noise.
• Notification and integration triggers. Route specific field changes to specific side effects — notify the billing team when plan_id changes, invalidate CDN caches when slug changes, push a webhook when price changes. Useful for prioritizing which integrations to build first.
• Risk decision on dependency hygiene. With 16 stars, 0 dependents, and a last release in April 2022, this is a reference implementation, not a supported dependency. The decision it supports is "adopt the pattern, not the package."

When to Consider This Package

Adopt it (or copy it) when:

• You need per-attribute model hooks and don't want to write the dirty-attribute comparison boilerplate yourself.
• You're prototyping a workflow, audit, or notification feature and want the hook layer resolved in an hour rather than a sprint.
• You're on a Laravel version contemporary with the 2022 release (Laravel 8/9, PHP 8.0–8.1) and can pin it.
• The team accepts vendoring or forking — at this size, copying the trait into app/Support is a legitimate adoption path and eliminates the maintenance concern entirely.

Look elsewhere (or build in-house) when:

• You're on Laravel 10/11/12 or PHP 8.2+. No release in three-plus years means no compatibility guarantee; expect to verify against your framework version before anything else.
• You need production SLAs, security review, or a support contact. Single maintainer, zero dependents, no evidence of battle testing — the bus factor is one.
• Your needs are already covered natively: Laravel's wasChanged(), getOriginal(), getChanges(), and Observers handle the large majority of field-level hook cases without a dependency. If your requirement is "do X when status changes," the framework does this today.
• You need complex conditional logic, ordering guarantees, or async side effects — that's a workflow/queue concern, not a trait concern, and a small package will become the wrong abstraction quickly.
• You require maintained dependencies as a policy. This fails a standard OSS intake review on recency and adoption alone.

Recommended disposition: treat as a design reference. Read the trait, extract the dirty-attribute pattern, and implement it locally in ~50 lines with tests. This captures 100% of the value at 0% of the dependency risk.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small open-source Laravel add-on that lets us trigger business logic when a specific field on a record changes — for example, kicking off a publishing workflow the moment a status field flips to published, rather than reacting to every generic save. The capability matters for our workflow, audit, and notification roadmap. The package itself does not: it's a 16-star, single-maintainer project with no dependents and no release since April 2022. Recommendation is to not adopt it as a dependency; the same behavior is roughly 50 lines of code we own, test, and can change freely. Net result: we get the feature, we take on no maintenance or security exposure, and we spend hours rather than a sprint.

To engineering (short): hashemi/fireworks is a trait that fires attribute-scoped model events via Laravel's native event system. Functionally sound, but unmaintained since 2022 and untested against Laravel 10+. We're recommending we vendor the pattern rather than require the package — implement field-change hooks in an Observer using wasChanged() / getOriginal(), with explicit tests. Same ergonomics, no version-pinning risk, and it stays inside our existing model-event conventions. If someone wants to spike with the actual package first, that's fine — just don't let it reach composer.json for production.