Cleaner Bundle Laravel Package

Technical Evaluation

Architecture fit

lamoda/cleaner-bundle is not a Laravel package. It is a Symfony bundle — a thin dependency-injection and configuration shim whose only job is to register and configure services from the underlying lamoda/cleaner library inside a Symfony kernel. In a Laravel application there is no bundle registration mechanism, so the package's actual deliverable (the bundle class plus Resources/config service definitions) is inert. The only transferable value is the core library it wraps, and even that must be assumed rather than verified given the repo state.

For a Laravel/PHP stack the realistic architectural verdict is: do not adopt the bundle; evaluate the core library at most, and only for a narrowly scoped, non-production capability (most plausibly test-fixture teardown / ordered data cleanup, which is the typical role of libraries in this family — confirm before relying on it).

Integration feasibility

• The bundle cannot be installed and used idiomatically in Laravel. You would either (a) depend on lamoda/cleaner directly and hand-write a ServiceProvider + config facade, or (b) extract the small amount of logic you need into first-party code.
• The bundle itself is near-zero effort to replicate: service definitions and a config tree are trivially rewritten as a Laravel provider binding. There is no hidden engineering value in the bundle layer.
• Because the package is archived with zero dependents, there is no community evidence of it working with modern PHP or modern Symfony — and therefore no evidence it works with the Laravel versions we run.

Technical risk

• Abandonment: critical. Archived repository, last release 2021-08-11, 2 stars, 0 dependents. No security response path, no PHP 8.2/8.3/8.4 compatibility guarantees, no bug fixes.
• Dependency rot: high. A 2021 Symfony bundle will pin or conflict with Symfony components that in turn constrain composer resolution in a modern Laravel app. Expect composer require conflicts before you ever reach runtime.
• Transitive exposure: unknown. Any Composer dependency of the core library is equally unmaintained; installing it imports that risk into our lockfile.
• Documentation/support: none. No active maintainer to escalate to; any defect becomes our defect.
• Scoring signal: a composite score of 0.05 aligns with the evidence; this should not clear a standard intake bar.

Key questions

1. What is the actual capability we want — ordered entity/data cleanup, PII scrubbing, cache/artifact purging? The answer determines whether a 20-line first-party implementation is sufficient.
2. Is lamoda/cleaner (core) still maintained and PHP 8.x-compatible, even though the bundle is archived? Check its own release history and constraint set before any further work.
3. Does the core library depend on Doctrine ORM/DBAL? If so, it is structurally misaligned with Eloquent and would require an adapter layer.
4. Is this a production runtime concern or dev/test tooling? Test-only scope dramatically lowers the risk calculus.
5. What is the cost of reimplementation versus the cost of fork-and-own? For a small utility, reimplementation is usually an order of magnitude cheaper than indefinite fork maintenance.

Integration Approach

Stack fit

Poor as packaged, workable only as extracted logic. The bundle assumes Symfony's kernel, DI container, and bundle config conventions. Laravel's service container, package discovery, and config publishing are different enough that the bundle would be dead weight in vendor/. Treat the package as reference material, not a dependency.

Migration path

1. Spike (0.5 day): Read the bundle's service definitions and the core library's public API. Document exactly what the library does and which of our problems it solves.
2. Decide build vs. borrow: If the capability is narrow (e.g., dependency-ordered deletion of records), implement it in first-party code against Eloquent. If it is genuinely substantial, vendor the core library only.
3. If vendoring the core: fork it under our org, add PHP 8.x and Laravel-version CI, pin the fork in composer.json via a VCS repository entry, and document the fork owner.
4. Laravel wiring: a CleanerServiceProvider registering the client as a singleton with a published config file — approximately the same surface the Symfony bundle provided.
5. Never install the bundle itself. No path to value justifies the resolution risk.

Compatibility

Verify before committing: PHP constraint in composer.json, Symfony component major versions, and whether the core library's constraints can coexist with our current Laravel and PHP versions. Assume they cannot until proven otherwise. There is no released version aligned to PHP 8.2+, and no maintainer to publish one.

Sequencing

Spike → capability gap assessment → build-vs-fork decision → (if fork) CI + ownership + security watch → Laravel service provider → test coverage. Do this in a single iteration; it should not become a multi-sprint workstream, and it should not block a release.

Operational Impact

Maintenance

Full ownership transfers to us on the day we adopt it. With the upstream archived, there is no upgrade path, no patch stream, and no maintainer relationship. Budget for periodic manual review of the fork against PHP and Laravel upgrades — a recurring cost that will never decrease. For a 2-star, zero-dependent package, this is almost certainly a worse trade than writing the equivalent logic ourselves.

Support

None. No issue triage, no security advisories, no CVE response. If a vulnerability is disclosed in the core library or its dependencies, we are the responders. This must be surfaced explicitly to security review; an archived upstream with unpatchable transitive dependencies is a common blocker for production inclusion.

Scaling

If the capability is used only in test/CI teardown, scaling is a non-issue — it runs at fixture volume. If someone later wires it into a production data-cleanup path, the failure profile changes: bulk deletion without chunking causes long transactions, lock contention, and replication lag on large tables. Gate this explicitly — document that adoption is dev/test scope only, and enforce it in code review.

Failure modes

• Install-time: Composer resolution conflict with current Laravel/Symfony components — fails loudly, low harm.
• Upgrade-time: Silent breakage when PHP or Laravel is bumped, because nothing tests the fork unless we add CI.
• Runtime (production misuse): Unbatched destructive operations, or cleanup ordering that misses a foreign-key dependency and aborts mid-run, leaving partial state.
• Security: Inability to patch. Highest-severity, lowest-visibility failure mode.

Ramp-up

Low technical ramp-up — the API surface is small and the bundle layer is trivial to replicate. The real ramp-up cost is organizational: establishing fork ownership, adding CI, registering a security-watch entry, and socializing the "test-only" usage constraint. That overhead likely exceeds the cost of a clean first-party implementation.

Recommendation: Reject as a dependency. Extract the underlying capability into first-party Laravel code (preferred), or fork the core library with explicit ownership and CI only if the spike proves the logic is non-trivial to reproduce.