Artisan Log Cleaner Laravel Package

Technical Evaluation

Architecture fit. hedii/artisan-log-cleaner is a single-purpose Laravel package: a service provider that registers one artisan command to remove log files from the app's log directory. It sits entirely in the operations tooling layer — no request-path code, no middleware, no schema changes, no impact on application architecture. That makes it architecturally "free" to adopt and equally free to remove. It is not a logging solution; it is a housekeeping utility that assumes file-based logging (single/daily drivers writing to storage/logs).

Integration feasibility. Low effort. Composer install, Laravel package auto-discovery, optionally publish the config to pin the target directory and file extension, then invoke the command manually or from the scheduler. There is no migration, no environment variable, and no runtime dependency. A competent Laravel developer can validate it in under a day.

Technical risk.

• Low blast radius, high consequence if misconfigured. The command deletes files irreversibly. The primary risk is scope: confirming exactly which directory, file pattern, and retention rule it applies before it runs unattended.
• Maintenance signal is mixed. MIT license and a 2025-03-18 release are positives, but 41 stars and a narrow maintainer base mean abandonment risk is real. The code surface is small enough that forking or reimplementing (~50 lines) is a credible fallback.
• Compatibility risk is concentrated at Laravel major upgrades, when service-provider and command-signature conventions shift.
• Multi-node ambiguity. On autoscaled or multi-host fleets, a per-host cron deletes only local files; whether that is correct depends on whether logs are also shipped to a central sink.

Key questions.

1. Does the command support age-based retention, or only wholesale clearing of matching files — and what is the default when no retention is configured?
2. Does it delete the currently active log file, and how does that interact with Laravel's daily rotation and in-flight writes?
3. What are the exact default target directory and extension, and can they be constrained to a subdirectory to avoid collateral deletion?
4. Does it follow symlinks or recurse, and is there a dry-run or verbose mode for safe validation?
5. Which Laravel and PHP versions are supported by the current release, and is there a stated support policy?
6. Does it fail loudly (non-zero exit) so scheduled runs can be alerted on?

Integration Approach

Stack fit. Appropriate for any conventional Laravel application using local file logging — the common case for internal tools, admin panels, and mid-size SaaS apps. It is a poor fit where logs are written to stderr/stdout (container-native patterns), shipped by a sidecar, or managed by the platform (CloudWatch, Loki, Papertrail). In those environments the package is redundant and potentially harmful if it deletes buffers before shipping.

Migration path. Additive and reversible:

1. composer require hedii/artisan-log-cleaner in a branch.
2. Publish and review the config; explicitly set the log directory and extension rather than relying on defaults.
3. Run the command manually in a non-production environment and diff the directory listing before/after.
4. If satisfactory, register a scheduled invocation; if not, composer remove — no residue beyond the config file.

Compatibility. Pin the package version in composer.json and let the lock file govern. Validate against the specific Laravel major in use, and re-validate as part of the standard framework-upgrade checklist. Where the framework version outruns the package, the fallback is a small custom command using File::delete() over storage/logs with a retention filter — a same-day task.

Sequencing.

1. Confirm logging architecture (file-based vs. centralized) — this decides go/no-go.
2. Validate in staging with a manual run and an explicit file inventory.
3. Enable on a schedule in staging for one retention cycle; verify disk-usage trend and absence of error-log loss.
4. Roll to production with alerting on non-zero exit.
5. Add to the runbook and the upgrade checklist; set a calendar review of package health (last release, open issues) each framework upgrade.

Operational Impact

Maintenance. Minimal ongoing effort: version bumps and an annual health check. The real maintenance obligation is governance — an assigned internal owner, a pinned version, and a documented fallback if the package goes dormant. Budget a few hours per year, plus a half-day whenever Laravel has a major release.

Support. Community-supported MIT package with no vendor SLA. Escalation path is the maintainer's issue tracker, then a fork. Treat it as "known-good utility code we could own" rather than a supported dependency; the small surface area makes internal ownership viable.

Scaling. The command is host-local and cheap — no meaningful CPU, memory, or I/O concern at typical log volumes. The scaling question is topological, not computational: on N hosts or ephemeral containers it must run on each node (or be replaced by centralized retention), and on ephemeral filesystems it may be unnecessary entirely. Define the retention policy once, centrally, and ensure the package is one implementation of it rather than the policy itself.

Failure modes.

• Over-deletion. Misconfigured directory or extension removes non-log files or the wrong environment's logs. Mitigate with explicit config, a staging dry run, and restricted filesystem permissions.
• Loss of forensic evidence. Aggressive retention destroys the logs needed for an incident investigation. Set retention from a stated policy (e.g., 14–30 days), not from disk pressure alone.
• Deleting the active file. Removing the currently written log can drop buffered records or produce permission errors until the handle is recreated. Prefer age-based retention that skips the active file, and schedule outside peak hours.
• Silent failure. Cron jobs that fail quietly give false assurance about disk usage. Require non-zero exits and alert on them; monitor free disk space independently.
• Upgrade breakage. A Laravel major upgrade changes command registration and the scheduled job stops firing without obvious error. Cover it in the upgrade checklist.

Ramp-up. Effectively zero for any Laravel developer: one composer command, one config review, one scheduler entry. The genuine ramp-up cost is procedural — writing the retention policy, the runbook entry, and the verification step — and that work is reusable regardless of which tool implements it.