Airdrop Laravel Package

Product Decisions This Supports

• Deployment velocity and time-to-market: Airdrop targets a specific, measurable pain — redundant front-end asset compilation during deploy. PMs can use it to improve deploy frequency and shorten the delivery lead time from merge to production without touching application code.
• CI/CD cost optimization: Skipping npm install/vite build when assets are unchanged directly reduces compute minutes and runner costs. This is a clean, quantifiable line item for platform-cost reduction initiatives.
• Build vs. buy vs. adopt decision: Airdrop is a small, MIT-licensed, single-purpose package. The decision is less "build vs. buy" and more "adopt a dependency vs. solve at the CI layer" (e.g., native pipeline caching). PMs should treat it as a make-or-break input into the deployment strategy, not a product feature.
• Developer experience roadmap: Faster deploys improve iteration speed and reduce context-switch pain during hotfixes. Relevant to DX/platform-engineering OKRs.
• Use-case fit for asset-heavy Laravel apps: Most valuable where front-end assets are large or slow to build but change infrequently relative to backend-only commits — common in monoliths and CMS-style apps.
• Platform/vendor lifecycle input (updated in v2.0.0): The package has moved from the original author (aaronfrancis/airdrop) to an organization (wilbergroup/airdrop). This is a governance change, not a rewrite: it modestly improves the "bus factor" story (an org-backed home rather than a single maintainer) but also means your dependency policy, package allowlists, SBOM, and license-scanning rules must be updated for a new Composer vendor name. Budget a small, one-time coordination cost.
• Forward-compatibility signal: v2.0.0 adds Laravel 13 support and PHP 8.5 to the test matrix. For PMs planning an upgrade cycle, this is a positive indicator that the package is being maintained against current framework versions rather than drifting.
• Risk/roadmap input: With ~197 stars (pre-transfer) and 0 dependents, this remains an early-stage package. Adoption should be weighed against maintenance risk, the churn implied by an org transfer, and the likelihood that the Laravel/Vite ecosystem or CI providers solve this natively over time.

When to Consider This Package

Consider adopting when:

• You run a Laravel application using Vite (or Mix) with a meaningful asset build step, and are on (or planning) a framework version covered by this release (Laravel 13 support is now explicit).
• Deploys are frequent and many changes are backend-only (PHP, config, migrations) that don't require asset recompilation.
• CI minutes or deploy times are a known bottleneck and you can attribute a meaningful share to asset compilation.
• You want a drop-in, low-effort optimization rather than re-architecting the pipeline.
• Your team is comfortable owning a small third-party dependency and pinning versions — now including the willingness to absorb a vendor-name change (composer require wilbergroup/airdrop) under a maintained lockfile and dependency-review process.

Look elsewhere or defer when:

• Your pipeline already caches assets effectively (Turbo, Nx, CI-native caching, Docker layer caching) — added value is marginal and you risk conflicting mechanisms.
• You're not on Laravel, or assets are trivially fast to build.
• You need commercial support, SLAs, or a large maintainer community — 0 dependents and a modest star count suggest limited battle-testing, and the org transfer is new enough that its long-term stewardship isn't yet proven.
• Correctness guarantees are critical: if a mis-detected "unchanged" state ships stale front-end assets, the failure mode is user-facing. PMs should require a rollback/override path and a verification step before betting on it.
• Your platform strategy already centralizes build caching (a platform team owning CI is often the better long-term answer).
• Your dependency governance can't absorb a rename quickly — e.g., an internal package proxy, allowlist, or security review gate that takes longer than the maintenance window you'd gain. In that case, defer until the next planned dependency-review cycle.

Upgrade note for existing adopters (v2.0.0): This is a breaking release, but the migration is mechanical — swap aaronfrancis/airdrop for wilbergroup/airdrop in composer.json and update the lockfile. Because trigger class names feed into the build hash, the first deploy after upgrading rebuilds assets once and then resumes skipping. Two PM-relevant consequences: (1) do not use that first post-upgrade deploy as your pilot baseline — it will show the old, slower timing and distort the measurement; (2) schedule the upgrade so the one-time rebuild doesn't land on a peak traffic window or an already-tight release train.

How to Pitch It (Stakeholders)

For executives (the business case):

"Airdrop is a small, free, open-source add-on for our Laravel deployments that skips rebuilding front-end assets when they haven't changed. It's a low-risk, low-effort lever to cut CI/deploy time and cloud spend, and to ship fixes to customers faster. It requires no infrastructure change and can be trialed behind a flag on one service before wider rollout. The package recently moved to a new organizational home and added support for the newest Laravel version — a modest maintenance-cost item for us (a one-line dependency rename plus a one-time asset rebuild on the next deploy), not a change in scope or risk profile."

For engineering leadership:

"It's a single-purpose, MIT-licensed package that short-circuits asset compilation based on change detection. The v2.0.0 release is breaking at the package-name level only — it moved to wilbergroup/airdrop, adds Laravel 13 and PHP 8.5 coverage, and the first deploy after upgrading recompiles assets once due to a hash change. We'd pilot it on one high-deploy-frequency service, measure deploy-time and CI-minute deltas starting after that first rebuild, and confirm the stale-asset failure mode is covered by an override and smoke test. If the ecosystem or our CI adds native caching, we retire it at near-zero cost."

For the immediate team:

"Faster deploys without touching app code — worth a two-week spike. Ship the rename to wilbergroup/airdrop first and treat the resulting rebuild as expected noise in the baseline. Main things to validate: detection accuracy for our asset setup, interaction with existing caches, whether our package-proxy/allowlist/SBOM tooling picks up the new vendor name cleanly, and whether the maintenance footprint is acceptable for a package with limited adoption so far."