Laravel Vendor Cleanup Laravel Package

Product Decisions This Supports

• Upgrade readiness and tech-debt prioritization: Gives teams a verified inventory of vendor-published files that are unchanged, orphaned, or stale, so you can decide whether to clean up before a Laravel/PHP major upgrade rather than carrying unknown config/view drift into it.
• Build vs. buy for maintenance tooling: Replaces ad-hoc Artisan commands or one-off scripts with a package that already handles JSON audit output, per-file verification, git-aware deletion, and AI-agent integration. The v0.13.0 release strengthens the buy case by adding verification and safer deletion semantics.
• AI-assisted maintenance roadmap: The vendor-cleanup-audit Boost skill is a low-risk candidate for piloting Laravel Boost / Claude Code workflows: it is read-only by default, pre-approves only audit commands, and escalates deletions through normal permission prompts.
• Scope control for cleanup work: Scoped runs such as /vendor-cleanup-audit config view let a PM or tech lead bound cleanup by file category, making it easier to schedule, review, and measure incremental cleanup instead of a risky big-bang deletion.
• Change-management and compliance: Verification marks unconfirmed findings instead of reporting them as fact; deletions use git rm only for user-selected files; migrations are never offered for deletion; files with local changes are never suggested for republishing. These are useful controls for teams with review requirements.
• Cross-platform developer experience: The case-insensitive filesystem fix removes false “missing” config reports on macOS and Windows, reducing noise and support burden for distributed teams.

When to Consider This Package

• Adopt when the Laravel application has accumulated files from vendor:publish over time — especially configs and views — and the team cannot confidently tell which copies still differ from vendor defaults.
• Adopt when the team is preparing for a major framework or package upgrade and wants to reduce config drift and upgrade friction before starting.
• Adopt when the team uses Laravel Boost 2.x and/or Claude Code and wants a guarded, verification-first cleanup skill rather than manual file-by-file inspection.
• Adopt when cleanup must be reviewable and reversible: the package’s read-only default, permission-gated deletions, git rm usage, migration exclusion, and “do not republish over local changes” behavior fit controlled change processes.
• Adopt when developers work on macOS or Windows, where case-insensitive filesystems previously caused false positives.
• Look elsewhere when the app has few or no vendor-published files, or the team already manages them manually with negligible drift.
• Look elsewhere when you need unattended, automated deletion in CI. This package intentionally requires human selection and permission prompts for deletions.
• Look elsewhere when the primary goal is cleaning migrations. The skill explicitly does not offer to delete migrations.
• Look elsewhere when you do not use Laravel Boost and do not want another development dependency, or when the team has no interest in AI-agent-assisted maintenance workflows.
• Onboarding note: adoption requires selecting leek/laravel-vendor-cleanup in php artisan boost:install’s third-party picker, then re-running boost:install or boost:update after upgrades so skill files are replaced.

How to Pitch It (Stakeholders)

• To executives: Position it as low-risk maintenance hygiene for Laravel applications. It helps remove stale copies of vendor-published config and view files, reducing upgrade surprises and configuration drift. The v0.13.0 release adds verification before findings are reported, read-only defaults, and permission-gated deletions, so it is suitable for a controlled pilot rather than a risky bulk-cleanup tool.
• To engineering leadership: Emphasize that the package does not blindly delete. It runs audit commands with --json, verifies each candidate by reading files, diffing, grepping references, and checking git history, and marks anything unconfirmed as “Not confirmed.” Deletions are limited to files the user selects, use git rm, exclude migrations, and avoid republishing files with local changes.
• To engineering teams: Pitch it as an optional development dependency and a safer alternative to manual vendor:publish archaeology. The Boost skill supports scoped audits by file type, guides users through cleanup choices, and can offload file-by-file verification to a Sonnet subagent in Claude Code to keep the main conversation cheaper.
• To security/review stakeholders: Highlight that allowed-tools pre-approves only the exact audit commands and a few read-only tools; deletions go through the normal permission prompt. The package is read-only by default and does not propose deleting migrations or overwriting local modifications.
• Pilot recommendation: Try it on one repository before a planned upgrade. Measure the number of verified stale/orphaned files found, time saved versus manual review, and reduction in upgrade-related config diffs. Keep it as a development tool, not a production runtime dependency.