Migrate Db Laravel Package

Getting Started

Minimal steps

1. Require the package at the current minor line so you inherit the 3.4 compatibility work:

   composer require <vendor>/<package>:^3.4
   

2. Confirm your framework constraint actually allows the resolution — check both composer.json files:

   composer show <vendor>/<package> | grep -E 'versions|requires'
   

3. Publish anything the package ships (config, migrations, views) before you write code against it, so you can see the real defaults rather than guessing at them.
4. Run the provider's boot path in a test rather than by hitting a route — a single php artisan about or a minimal feature test on your lowest supported Laravel version catches almost every integration problem.

Where to look first

• README.md — the canonical usage surface for this package; the 3.4.0 release changed no documented behaviour, so the existing README remains authoritative.
• CHANGELOG.md / GitHub releases — 3.4.0 is additive only.
• composer.json — the single most important file in this release. The Laravel 13 support is expressed there as an expanded illuminate/* constraint, not as new code.
• After publishing, the package's own config file. Read it once end-to-end; Helldar-family packages tend to expose behaviour through config keys rather than constructor arguments, so the config is the API.

First use case

The realistic first use case for 3.4.0 is not "adopt this package" but "unblock a Laravel 13 upgrade." If you're currently pinned to a 3.3.x line because the framework constraint excluded Laravel 13, this release lets you bump both in one commit and stop carrying a composer.json conflict workaround. Start there: bump the package, run composer update --dry-run, and read what moved.

Implementation Patterns

Upgrading in place (Laravel 11/12 → unchanged)

3.4.0 contains no breaking changes and no deprecations. Bump the constraint, run your existing test suite, ship it. There is no migration step and no config key rename to chase.

composer require <vendor>/<package>:^3.4 --update-with-dependencies
composer update --dry-run   # confirm nothing unexpected was dragged along

Framework major bump (→ Laravel 13)

Do the framework and this package in the same commit. Splitting them produces a composer.json that cannot resolve, which makes bisecting a failed CI run much harder than it needs to be.

{
  "require": {
    "php": "^8.3",
    "laravel/framework": "^13.0",
    "<vendor>/<package>": "^3.4"
  }
}

Run composer why-not laravel/framework 13.* before touching anything — it names the exact package and constraint blocking you. In practice this package was rarely the blocker; your other direct dependencies are.

CI matrix

If you maintain a package or a multi-version app, add 3.4.0 to the matrix at both ends of the supported range. The value of this release is the breadth of the constraint, so testing only on your own Laravel version verifies nothing:

strategy:
  matrix:
    laravel: ['11.*', '12.*', '13.*']

Auto-discovery

Confirm the service provider is registered by Laravel's package discovery rather than by a manual entry in config/app.php — this package family relies on discovery, and a stale hand-written entry in a legacy app can shadow the discovered provider and pin you to an old registration path. Check with:

php artisan about   # providers section

Version pinning

Use ^3.4, not dev-main or *. Because a meaningful fraction of this project's recent commits are bot-generated housekeeping (banner images, preview assets, LICENSE year), tracking an unstable branch gives you churn on files that cannot affect runtime behaviour.

Gotchas and Tips

Read the diff, not the release notes. Of the four PRs in 3.4.0, three are automated housekeeping (#50 LICENSE year, #51 preview, #52/#55 banner images). Only #54 touches anything a developer cares about — and that one is a composer.json constraint change. The release notes make the release look larger than it is; the actual runtime surface changed by zero lines of PHP. Conversely, don't assume future bot-author commits are inert: always diff composer.json and src/.

Laravel 13 support ≠ Laravel 13 released. An expanded constraint usually lands before the framework's stable tag, in which case resolution falls through to a 13.x-dev requirement and you inherit an unstable framework. Verify what actually resolved:

composer show laravel/framework | grep versions

If it says dev-, you are not on a stable stack regardless of what this package claims to support.

Transitive compatibility is the real bottleneck. This package supporting Laravel 13 does nothing for the four other packages that still cap at ^12. Resolve the why-not output for each blocker before committing to the upgrade window.

Don't composer update wholesale to get this fix. Use the targeted --update-with-dependencies form so you move this package and its dependency subtree rather than your entire lockfile. On a Laravel major bump, a full update can silently advance unrelated packages past their own breaking changes and make the failure impossible to attribute.

Extension points. Before reaching for a class override, check the config file — behaviour gated by config keys is the intended customisation path. Where the package registers bindings in its provider, a container binding in your own provider is the clean override; subclassing the package's concrete classes couples you to internals that are not covered by this project's semver promises.

Debugging failed resolution. In order of usefulness: composer why-not <package> <version> → composer update --dry-run -vvv → composer diagnose. For runtime issues post-upgrade (rather than install issues), php artisan about plus a clean php artisan config:clear resolves most "it worked on 3.3" reports, since a stale cached config is the usual culprit after a constraint bump.

Watch the release cadence. This project leans heavily on CI-generated PRs, which is fine for hygiene but means release notes are a poor signal for "should I care." Subscribe to the composer.json and src/ paths specifically, and treat anything else as noise.