Plume Laravel Package

Product Decisions This Supports

• Build vs. buy on frontend asset delivery: this release lowers the operational cost of buying. Asset publishing to public/vendor/plume with content-hashed filenames is solved-for-you plumbing — the kind of thing a team usually rebuilds badly in-house. The new plume:update-assets command removes the one remaining "we have to hand-manage this" objection by making stale-artifact cleanup a single idempotent step.
• Deployment reliability / release-engineering roadmap: the command is explicitly designed to be inserted into a deploy script after composer install/composer update. That makes it a candidate for standardization across services rather than a per-project workaround. If you maintain a shared deploy pipeline or base image, this is a checklist item, not a product feature.
• Support-cost reduction: stale hashed files at public/vendor/plume are a classic source of "users seeing old CSS/JS after deploy" and "disk slowly filling with orphaned assets" tickets. Automating the purge converts a recurring class of bug report into a one-line deploy step — a cheap, measurable win.
• Upgrade-path viability: the fact that the maintainer shipped a deploy-hygiene command signals they are thinking about the post-install lifecycle, not just the happy path. That is a positive signal for multi-environment (staging → prod) rollouts and for teams that pin versions and upgrade on a cadence.
• Sequencing decision: this is a patch-level release (0.10.5) that adds a feature. Treat it as evidence the package is still pre-1.0 and moving quickly — supportive of adoption for internal tooling, less supportive for anything customer-facing and frozen.

When to Consider This Package

Consider adoption when:

• You are already publishing Plume's assets into public/vendor/plume and have hit, or anticipate, stale-file or orphaned-hashed-asset problems after upgrades.
• Your deploy pipeline has a well-defined post-composer install hook (Envoyer, Deployer, GitHub Actions, Forge scripts, Docker entrypoint) where php artisan plume:update-assets can be added deterministically.
• You want a maintenance-light dependency and are comfortable tracking a pre-1.0 package, i.e. you can absorb minor breaking changes on your own schedule.
• Your team values explicit, inspectable deploy steps over "it just works" magic — a documented Artisan command is auditable in code review in a way that implicit publish hooks are not.

Look elsewhere or wait when:

• You need a stable public API with semver guarantees before committing (v0.10.x implies the surface can still move; feature additions in patch releases confirm loose versioning discipline).
• You require long-term support, security policy, or an upgrade guide — one release note is not enough evidence of those.
• Your asset pipeline already owns cache busting end-to-end (Vite/Mix manifests, CDN invalidation, container image rebuilds). A second, package-specific asset directory is a parallel system you would rather not introduce.
• Your deploys are immutable-image based and already guarantee a clean public/ — the command is harmless but adds no value, and "run this after composer update" instructions can conflict with read-only filesystems and multi-stage builds.
• You are evaluating whether the package is actively maintained: a single release note tells you about one command, not about issue triage, test coverage, or release cadence.

How to Pitch It (Stakeholders)

For executives (one line): a small upgrade that removes a recurring class of deployment bug — stale frontend files served to users after a release — at the cost of one line in our deploy script.

For engineering leads: version 0.10.5 adds plume:update-assets, which deletes the previously published assets at public/vendor/plume and republishes current ones. Wire it into the deploy pipeline immediately after composer install/composer update. This is the sanctioned fix for orphaned hashed files and post-deploy cache-staleness, and it replaces whatever ad-hoc cleanup (if any) we currently do by hand. Document it in the runbook and in the base deploy template so it is not re-learned per project.

For the product/roadmap conversation: treat this as a reduce operational drag item, not a feature. The meaningful decision it informs is whether we standardize the deploy step and whether we accept the pre-1.0 risk of the dependency. Recommended posture: adopt for internal tooling, pin the version, and reassess at 1.0 or at the next minor bump — with a standing expectation that upgrades require reading release notes, since this maintainer ships features in patch releases.