- What is aaronfrancis/airdrop used for in a Laravel app?
- Airdrop is a deploy-time utility that speeds up Laravel deployments by skipping frontend asset compilation when the inputs that affect the build are byte-identical to a previously recorded build. It is meant for projects using Vite and a repeatable CI or deploy pipeline. The value is narrow but real: fewer build minutes and faster deploys when a release only changes PHP, config, or templates. It is a pipeline dependency, not a runtime package in your application.
- How do I install and configure Airdrop in a Laravel project?
- Install it with Composer, publish the package config file, and wire its command into your deploy script before the npm build step. You also need to persist the state or manifest file between deployments so Airdrop can compare current build inputs to the last recorded build. The PHP integration is straightforward; the harder part is making sure your CI runner or deploy system keeps that state file available across runs.
- Which Laravel and PHP versions does Airdrop support?
- The documented integration approach targets Laravel 10 through 12 with Vite, Composer 2, and Node 18, 20, or 22. PHP version constraints and the exact supported Laravel range should be verified in the package composer.json before you pin it. If you are on an older Laravel version, check the repository tags and CI matrix rather than assuming compatibility.
- How does Airdrop decide whether to skip the asset build?
- Airdrop hashes the inputs that affect your frontend build, such as package.json, the lockfile, bundler configuration, resources/js, and resources/css, then compares that hash to the previously recorded build. If the inputs match, it can skip npm ci and npm run build. Exactly which files and config keys are included matters, so review the source or ask the maintainer whether your environment-specific inputs are covered. Inputs like VITE_* variables, Node version drift, or .npmrc changes may not be part of the hash by default.
- Where does Airdrop store its build state, and does it work with ephemeral CI runners?
- Airdrop records state in a manifest file that must survive between deployments. On ephemeral CI runners you need to cache or persist that file using CI cache, an artifact store, or a Docker cache mount. If the file lives in a temporary path, the optimization silently does nothing rather than breaking the build. For shared or concurrent deploys, confirm that the storage location is safe and that parallel runs cannot corrupt the state.
- What happens if Airdrop's state file is missing, corrupted, or unreadable?
- You should verify this behavior before relying on Airdrop in production, because the safe default is fail-open: rebuild the assets when state cannot be read. A missing state file typically means no previous build is recorded, so a build should run. Corruption or partial writes are more concerning, especially if the manifest is stored in a shared mutable location. If the package does not fail open, add a guard in your deploy script or fork and pin the package.
- Is there a force rebuild or bypass option in Airdrop?
- A force or bypass flag is an important operational control for hotfixes, rollbacks, and suspected stale-asset incidents. The repository documentation should be checked for a --force option or equivalent escape hatch. If none exists, you can bypass the optimization by deleting the state file or running the frontend build manually before the Airdrop step. Treat this as a required capability for production use and confirm it with the maintainer.
- Can Airdrop ship stale assets when VITE_* environment variables or Node versions change?
- Yes, that is the highest-risk failure mode. If an input that affects the build is not included in the hash, such as VITE_* variables baked in at build time, Node or bundler version drift, or an unusual Tailwind or PostCSS config location, Airdrop may falsely decide nothing changed and skip the build. That can silently ship stale or wrongly configured assets. Extend the hashed input set or force builds whenever those values change.
- How should I test Airdrop before using it in production?
- Start in shadow mode: install the package and log the would-skip or would-build decision without actually skipping the build for two to three weeks across all deploy types. Measure the skip rate and compare p50 and p95 deploy duration and build minutes with and without Airdrop. If the skip rate is below roughly 30 percent or the savings are under a minute, the coordination cost is probably not worth it. Shadow mode gives you a free measurement before accepting any stale-asset risk.
- Is aaronfrancis/airdrop actively maintained, and what are the alternatives?
- Treat Airdrop as a small, lightly adopted utility: the repository points to a WilberGroup fork, the package has roughly 197 stars and no dependents, and you are effectively your own maintainer if you adopt it. The MIT license makes forking and pinning viable, but verify tags, changelog, and commit history before relying on it. Alternatives include always building assets, using GitHub Actions or Docker layer caching, or writing a small hash check in your deploy script. For many teams, native CI cache plus a fast Vite build is simpler and safer.