Cleaner Bundle Laravel Package

Getting Started

First, the reality check. This bundle is archived, last released 2021-08-11, with 2 stars and 0 dependents. Do not add it to a new project. Read it as a reference implementation, and only install it if you are maintaining a legacy Symfony 4/5 app that already depends on it.

If you are evaluating it anyway, look here first, in this order:

1. composer.json — check the symfony/* and php constraints. A 2021 bundle almost certainly caps out below Symfony 6, and possibly below PHP 8.1. This single file decides whether the package is even installable for you.
2. DependencyInjection/Configuration.php — this is where the entire public surface of the bundle lives. It is a thin wrapper, so the config tree is effectively the documentation.
3. DependencyInjection/LamodaCleanerExtension.php — confirms which services get registered, whether they are public, and how the underlying cleaner services (usually tagged or aliased) are wired into your DBAL connections.
4. The upstream lamoda/cleaner README — the bundle is glue; the actual cleanup strategies and their behaviour live in the library.

Minimal setup (legacy app):

composer require --dev lamoda/cleaner-bundle

It belongs in require-dev: cleanup is a test-time concern. Register it manually in config/bundles.php (there is no Flex recipe for a 2-star archived bundle):

Lamoda\CleanerBundle\LamodaCleanerBundle::class => ['test' => true],

Restrict it to the test environment so it never appears in prod containers.

First use case: truncating or deleting rows from your application tables between integration tests, so each test starts from a known empty state without paying the cost of a full schema rebuild. If that is not your use case, this package is not solving a problem you have.

Before committing, price the alternatives. dama/doctrine-test-bundle (transaction rollback), Doctrine's DoctrineFixturesBundle purger, or a five-line TRUNCATE helper in your test base class all cover the same ground with active maintenance. The bar for adopting an archived package is high.

Implementation Patterns

Inject the cleaner, don't reach for the entity manager. The bundle's value is that it produces a configured cleaner service bound to your DBAL connections. Consume it through the container in a test base class so a config change (adding a table, switching strategy) does not touch test code:

abstract class DatabaseTestCase extends KernelTestCase
{
    protected CleanerInterface $cleaner;

    protected function setUp(): void
    {
        self::bootKernel();
        $this->cleaner = self::getContainer()->get('lamoda_cleaner.cleaner');
        $this->cleaner->clean();
    }
}

Adjust the service id to whatever the extension actually registers — with a thin bundle the id is not guaranteed to be the intuitive one, so grep the extension class once and hardcode it behind a constant.

Clean before, not after. Purging in setUp rather than tearDown means a failing test leaves its data in the database for inspection. Purging after also silently masks ordering bugs between tests.

Allow-list your tables explicitly. Cleanup that defaults to "everything in the schema" will eventually eat a migrations table, a queue table, or reference data seeded once for the whole suite. Configure the table list explicitly and treat it as part of the test contract — when you add a table, you add it to config, and that is a feature, not friction.

Pair with fixtures rather than replacing them. The idiomatic flow is: clean → load fixtures → run test. Cleanup gives you the empty baseline; fixtures give you the specific rows. Keep fixture loading in a separate trait so you can run tests that need no fixtures at all without paying the load cost.

Multi-connection apps need per-connection config. If the bundle follows the library's shape, each configured connection gets its own cleaner service. Inject the right one per test case rather than assuming a single global cleaner; a cleaner bound to connection A will happily succeed while your assertions read connection B.

Use it as a specification. Since the bundle is archived, its highest-value use today is as a worked example of how to wire a cleanup strategy into Symfony DI: a compiler pass or tagged services, a configuration tree, per-connection factories. If you build your own internal cleaner, copy that structure and skip the dependency.

Gotchas and Tips

Archived means frozen. No security patches, no PHP 8.x compatibility work, no Symfony 6/7 support, and issues will not be answered. Treat any composer update that touches this package as a manual review.

Foreign keys are the number one failure mode. Truncation with TRUNCATE will fail (or silently cascade, depending on engine) when FK constraints exist. Either disable FK checks around the cleanup, use a delete strategy that respects ordering, or configure the strategy that handles constraints. Decide this explicitly and write a test that asserts cleanup succeeds on a fully-migrated schema — that test is your early warning when someone adds a new FK.

Identity sequences drift. Truncating rows does not always reset auto-increment counters. Tests that assert on hardcoded IDs or counts derived from sequence values will pass locally and fail in CI, or vice versa. Either reset sequences as part of cleanup or stop asserting on generated IDs.

Mixing with transactional tests breaks things. If you wrap tests in a transaction for rollback, cleanup inside that transaction may deadlock against the truncate, or the truncate may be rolled back along with everything else. Pick one strategy: transaction rollback or truncate-and-reload. Never both.

Parallel test runners and shared databases are a trap. A cleanup strategy that empties tables is incompatible with paratest-style parallelism unless each worker gets its own schema or database. This is usually discovered in CI, not locally.

Debugging empty results. When a test unexpectedly sees no rows, check in this order: (1) is the cleaner bound to the connection your assertions use, (2) did your setUp ordering run cleanup after fixture loading, (3) is the table in the configured list at all. A cleaner configured with an empty table list can be a no-op that looks like a fixture bug.

Container compilation errors at boot usually mean the bundle expects a DBAL connection alias that your app names differently. Check Configuration.php for the required connection key and confirm it matches a real doctrine.dbal.connections entry for the test environment specifically.

Extension points worth noting if you fork it: the strategy object (truncate vs. delete) and the per-connection cleaner factory are the two seams that matter. Everything else is configuration plumbing. If you need behaviour beyond those two, you are better off writing ~50 lines in your own test support layer than patching an archived bundle.

Migration path: replace the cleaner service with a small internal TableCleaner wrapping your DBAL connection, keep the exact same clean() interface, and delete the dependency. Your test base class will not need to change.