Airdrop Laravel Package

Product Decisions This Supports

• Deploy-time budget as a product constraint. Airdrop targets a specific, measurable waste: recompiling front-end assets during deploys when the inputs haven't changed. That makes it a lever for a "deploy in under N minutes" goal rather than a vague performance initiative. Any roadmap item gated on deploy frequency or preview-environment availability (faster iteration, per-PR environments, hotfix turnaround) gets cheaper to justify if the build step is conditional rather than unconditional.
• Build vs. buy (vs. build-in-an-hour). The underlying logic — hash the asset sources, compare to the last build, skip vite build if unchanged — is genuinely small. The buy case isn't capability, it's edge cases: lockfile changes, config changes, partial builds, cache invalidation, CI vs. local parity, and now the maintenance/ownership question. Treat this as a "buy a maintained convention for ~free" decision, not a "buy a platform" decision. The MIT license and drop-in nature mean the exit cost is near zero (one pipeline step to delete), which lowers the threshold for trying it.
• Ownership risk as a factor in dependency decisions. v2.0.0 moves the package from a personal namespace (aaronfrancis/airdrop) to an organization (wilbergroup/airdrop), alongside Laravel 13 and PHP 8.5 support. For a PM this is a net-positive signal — an org-backed home with a maintained test matrix is more durable than a solo namespace — but it is also a package-identity change, which is the category of event that breaks composer.json files, CI caches, and internal documentation. Budget the migration as a small, scheduled chore, not a surprise.
• CI spend and pipeline investment. Every skipped build is CI minutes not billed and a shorter critical path in the deploy job. This supports decisions like: standardize asset-skip across all Laravel services, or invest in broader build caching (Docker layer caching, dependency caches) versus solving it at the framework layer. Airdrop is the narrow, cheap option; broader caching is the platform option. Knowing which one you're buying prevents over-scoping.
• Where it fits in the use-case portfolio. Highest value where a large share of deploys don't touch front-end code: backend-only PRs, config and copy changes, docs and migration work, monorepos where one of several apps changed, and ephemeral preview/review apps that rebuild constantly. Low value for design-heavy products where nearly every deploy ships CSS/JS changes.
• Roadmap and org signals it enables. Cheap, reversible deploy wins are good candidates for a "developer experience" workstream that shows measurable results in one sprint. If the pilot shows a large share of builds skipped, that's evidence to also invest in preview environments and faster release cadence; if it shows almost none, that's evidence your constraint is elsewhere (tests, migrations, image builds) and the team should stop optimizing the asset step.

When to Consider This Package

Good fit when several of these hold:

• Laravel app using Vite with a conventional resources/ → build output layout; standard npm run build in the deploy pipeline.
• Deploy frequency is high enough that build minutes and deploy latency are visible costs — daily or multiple-per-day deploys, or many environments per app.
• A meaningful fraction of deploys are backend-only or non-asset changes.
• You run ephemeral environments (PR previews, per-branch staging) where the same assets get rebuilt repeatedly.
• You want a framework-level, per-app solution rather than re-architecting CI caching.
• You are on a supported combination: Laravel through 13 and current PHP (8.5 is now in the upstream test matrix), on a pinned package version. Note that v2.0.0 is a breaking release — the Composer name changed to wilbergroup/airdrop, so existing installs must update composer.json and any CI references, and the first deploy after upgrading rebuilds assets once because trigger class names feed the build hash.
• You can tolerate a small dependency with modest adoption. The org transfer improves the durability story, but it is still community-grade with a single-maintainer history, so keep a fallback (the plain npm run build command) that costs nothing to revert to.

Look elsewhere when:

• Deploys are infrequent or assets change on nearly every deploy — the skip rate won't repay the added pipeline complexity or the "why didn't my CSS update?" debugging class of bug.
• Your CI already caches effectively and the build is a rounding error next to test suites, image builds, or migrations. Optimize the actual critical path.
• You have a non-standard asset pipeline (multiple bundlers, runtime-compiled assets, assets built outside the deploy job, or build artifacts checked in). Conditional builds assume a clean, single source of truth for when assets are stale.
• Procurement or platform standards require a supported vendor, an SLA, or a dependency with a formal security response process. The organization move helps perception, but there is still no support contract; assume you may own the code.
• The team can't easily verify correctness. If nobody can answer "how do we know the built assets match the source?" in one sentence, don't adopt conditional builds yet — regardless of tool.
• You cannot absorb a namespace migration right now. If you are mid-freeze or mid-audit, pin the last v1 release, note the rename in the dependency register, and schedule the bump — a package rename is a poor fit for a change window that can't tolerate a one-time forced rebuild.

Practical adoption criteria: pin the version explicitly (and pin the new wilbergroup/airdrop name, not the legacy one), confirm Laravel/PHP/Node compatibility against your matrix — v2.0.0 is the release that unblocks Laravel 13 and PHP 8.5 shops — verify the org transfer against the upstream repository history and changelog before pulling it into production, run it in one non-critical service for a few weeks, and instrument skip rate plus any "stale assets" incidents before rolling out broadly. When reading pilot numbers, discard the first deploy after any upgrade: a hash-input change forces one legitimate rebuild.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our deploys currently rebuild front-end assets even when nothing front-end changed, which costs CI minutes and adds latency to every release — including backend-only fixes. Airdrop is a small, MIT-licensed Laravel package that detects when assets are unchanged and skips the rebuild. It's a low-cost, fully reversible optimization: no architecture change, no vendor contract, removable in one commit. The newest release moves it under an organization (wilbergroup/airdrop), adds Laravel 13 and PHP 8.5 support, and is a drop-in replacement that requires a one-line Composer rename and a single unavoidable rebuild on the first deploy. Expected value is faster deploys and lower CI spend, scaling with how often we ship. Recommended path is a four-week pilot on one service with two numbers tracked — share of builds skipped and deploy duration — then a go/no-go.

For engineering: It's a pipeline-level guard, not a build-system replacement. If asset inputs are unchanged, the existing compiled output is reused instead of invoking the bundler; otherwise it behaves exactly as today. Integration is a package install plus pipeline wiring, and the rollback is deleting one step and running the normal build. v2.0.0 specifics to plan for: the namespace moved to wilbergroup, so composer require and any doc/CI references change; trigger class names are part of the build hash, so expect exactly one full rebuild on the first deploy after upgrading before skipping resumes; and this is the release that carries Laravel 13 and PHP 8.5 support, which matters for our upgrade matrix. Review the upstream diff and changelog as part of the rename, since a namespace transfer is also a supply-chain checkpoint — then pin the new name and version. The correctness question to answer up front in code review is still "what exactly counts as an asset input change?" (source files, lockfile, build config, trigger classes), because that determines both the skip rate and the failure mode. Success looks like a high skip rate with zero stale-asset incidents; anything else, and we remove it.