Recurrent Fixtures Test Bundle Laravel Package

Getting Started

The v0.1.12 release widens the package's doctrine/dbal constraint to support both ^2.0 and ^3.0. This is a compatibility release rather than a feature release: no new public API is introduced, but it changes which DBAL version your application will actually resolve.

• Install and confirm what you got. Run composer require <vendor>/<package> and then composer show doctrine/dbal to verify whether Composer resolved DBAL 2 or 3. Your framework version, other packages, and PHP version all influence the outcome, so never assume — check the lock file.
• Look first at composer.json and the service provider. The constraint change is the signal that the package touches DBAL schema APIs. The service provider is where any DBAL type registrations or schema-builder bindings will be wired up, so that is the first file to read.
• Pin your expectations deliberately. If your app is on Laravel 10 or earlier, DBAL is the mechanism behind ->change() and related schema operations. If you are on Laravel 11+, native schema operations largely remove the need for DBAL, and the package's role may be reduced to type registration or introspection.
• First use case: attempt a column modification or schema introspection call through the package on a disposable database. That single exercise will tell you which DBAL major version is installed and whether the package's abstractions hold for your stack.

Implementation Patterns

• Treat the version pair as your primary configuration axis. The package now spans two majors with materially different internals. Document which DBAL major your project resolves and standardise on it across local, CI, and production so behaviour does not drift between environments.
• Isolate DBAL touching code. Wrap schema introspection, column modification, and custom type work behind a small application-level service or repository method. When DBAL 2 reaches end of life, that boundary is the only place you need to change.
• Composer hygiene. Add doctrine/dbal to your own composer.json if you consume its types or schema classes directly, rather than relying on the package's transitive constraint. This makes your dependency explicit and prevents a future package bump from silently moving your DBAL version.
• CI matrix. If you maintain packages or libraries that depend on this one, test against both DBAL majors now that the constraint permits it. A two-cell matrix against the lowest and highest supported versions is a cheap way to catch divergence early.
• Migration workflow. For projects still on older Laravel versions, keep column-changing migrations isolated so they can be run and reviewed independently. Wide DBAL support means you can upgrade DBAL without a Laravel upgrade — treat those as separate, sequenced changes.
• Upgrade sequencing. Upgrade DBAL first on a branch, run the full test suite, then upgrade the rest. Do not combine a DBAL major bump with framework or PHP upgrades in a single change; the failure surface becomes difficult to attribute.

Gotchas and Tips

• This release is not itself a breaking change, but it opens the door to one. Widening a constraint means Composer may now resolve a version it previously refused to install. Always run composer update doctrine/dbal -W deliberately and review the diff, rather than letting a routine update drift you across majors.
• DBAL 3 removed and deprecated APIs that DBAL 2 users rely on. Type registration, platform type mapping, and schema manager access have all shifted. If the package exposes any of these transitively, expect different behaviour and different exception surfaces depending on the resolved major.
• Silent version skew across environments. The most common failure mode with widened constraints is local resolving to one major and production to another. Lock the version in composer.lock and commit it; verify in CI with composer show doctrine/dbal.
• Laravel version interaction. DBAL is a hard requirement for ->change() on Laravel 10 and below, and largely unnecessary on Laravel 11+. Before debugging a schema error, confirm whether the framework or the package is actually driving the operation.
• Test against real databases. DBAL's platform detection differs from Laravel's grammar layer, and SQLite in-memory tests frequently mask issues that appear on MySQL or PostgreSQL. Run at least one schema-touching test path against your production engine.
• Debugging tip. composer why doctrine/dbal immediately reveals whether the version in play came from this package, from Laravel itself, or from another dependency. Do this before reading any package source.
• Extension points to inspect. Look for a published config file, a registerDoctrineTypeMapping call, and any custom Doctrine\DBAL\Types\Type subclasses. These are the places where a DBAL major bump is most likely to require attention from you.
• Watch for deprecation noise. DBAL 3 emits deprecations for paths that DBAL 4 will remove. Do not suppress them; they are an early warning that your next upgrade will not be as frictionless as this one.