tabuna/memento
Memento is a Laravel package for tracking changes to Eloquent models. It stores model snapshots so you can review revision history and restore previous states, adding lightweight auditing without complex setup.
esplora/memento is a small, focused utility package — the kind you install once and then call from a handful of places rather than build an application around. Version 3.0.0 is a maintenance-oriented major release: it adds Laravel 10, PHP 8.2 and PHPUnit 10 support, and by implication drops support for the older framework/runtime versions that 2.x targeted.
Minimal steps:
composer require esplora/memento:^3.0
^2.0 until you upgrade — 3.0.0 will not resolve.config/app.php if the README explicitly says to.vendor:publish --provider="Esplora\Memento\...") — config file, migrations, or stubs. Read the published config before you change anything; defaults are usually the intended path.README.md, src/ (it is small enough to read end to end in ten minutes), the service provider, and tests/. The tests double as executable documentation and tell you exactly which contracts are guaranteed.First use case: pick the one place in your app where you currently have duplicated logic that the package formalises, wire it in there alone, and let it bake for a release cycle before spreading it around. For a package this size, an incremental adoption is almost always cheaper than a wholesale refactor.
Verify the integration surface before writing code. Because 3.0.0 is a compatibility release rather than a feature release, the public API is expected to be unchanged from 2.x. Confirm this yourself with a quick diff of src/ between the two tags (composer diff or the GitHub compare link in the changelog) — that is faster and more reliable than trusting the release notes.
Wrap it behind your own boundary. Even for a tiny package, do not call it from twenty call sites. Put the calls behind one class or one trait in your app/ namespace, and let the rest of your code depend on that. When the next major arrives (and this package has now shown it does majors for framework support), you change one file instead of grepping the codebase.
Configuration over code where possible. If the provider merges a config file, publish it and set values via config/memento.php (or the equivalent) using env() only inside the config file itself — never call env() from application code, or config:cache will silently break you.
Test with PHPUnit 10 conventions. If your own suite is on PHPUnit 9, upgrading your test dependencies to ^10 is part of adopting this package. Watch for:
@dataProvider / @depends / @test docblock annotations — PHPUnit 10 still tolerates many of them but emits deprecations; move to #[DataProvider], #[Depends], #[Test] attributes.assertObjectHasAttribute / assertObjectNotHasAttribute — removed; use assertObjectHasProperty.final or readonly members behaves differently; if you mock package internals, prefer mocking your own wrapper.CI matrix. Rather than testing the full cross-product, test the pairings you actually deploy: php: 8.2, laravel: 10 and php: 8.3, laravel: 10 (plus 8.2/11 if you also support Laravel 11 — check whether the constraint in composer.json is ^10.0 or ^10.0|^11.0; the release note only names Laravel 10).
Local development workflow. Use orchestra/testbench for any integration test that needs the framework booted, and pin it to the version matching Laravel 10 — a mismatched testbench is the single most common cause of "works in the app, fails in the package's tests".
Treat the major bump as a breaking change for consumers, even though the notes only mention additions. SemVer majors on Laravel packages almost always encode a dropped minimum: composer.json in 3.0.0 will constrain php: ^8.2 and illuminate/*: ^10.0. If your app's composer.json still allows PHP 8.1, composer update will fail resolution rather than silently degrade — read the error, don't fight it.
The changelog is thin. "added laravel 10, php 8.2, phpunit 10" is a single PR from a first-time contributor with no linked issues, no deprecation notices and no UPGRADE guide. That is fine for a small package, but it means you should read the diff before upgrading a production app. Specifically check for: removed classes/methods, changed constructor signatures, renamed config keys, and any @deprecated markers that were scheduled for removal in this major.
No upgrade guide is a signal about maintenance posture. With one contributor and a changelog this short, budget for doing your own archaeology. Pin to ^3.0 but commit your composer.lock, and if you cannot find time to review the diff, stay on ^2.0 — nothing in this release suggests a security or correctness fix that forces your hand.
Debugging. For a package this small, the fastest debug path is dd()/dump() inside your own wrapper, or step into src/ directly during a test run — the vendor directory is readable and the codebase is small enough that you should not need a debugger. If behaviour differs between CLI and HTTP, suspect config caching first:
php artisan config:clear
php artisan cache:clear
php artisan optimize:clear
PHPUnit 10 gotchas bite at the edges. If you use Pest, you need Pest v2 for PHPUnit 10 compat. If you use phpunit.xml schema attributes from PHPUnit 9, run vendor/bin/phpunit --migrate-configuration — the auto-migration is reliable and painless.
Extension points. For utility packages of this shape, the intended extension surface is usually (a) the config file, (b) swapping a binding in the container in a service provider, and (c) extending a base class. Confirm which of these the package actually supports before subclassing anything — with one maintainer, an unadvertised extension point is effectively private API and can vanish in the next minor.
Watch the repository, not just the changelog. Given the low release cadence and single-maintainer status, subscribe to the GitHub releases feed. A stale dependency that nobody is watching is the one that surprises you eighteen months later when you try to move to Laravel 12.
How can I help you explore Laravel packages today?