Laravel Storage Dedupler Laravel Package

Getting Started

1.0.3 is a compatibility release: it adds Laravel 13 support. That single line is the whole changelog, so treat this release as "unblock the upgrade," not "learn a new API."

Minimal steps:

composer require vendor/package:^1.0.3
php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
php artisan config:clear && php artisan cache:clear

Where to look first:

• composer.json of the package — confirm the constraint is now illuminate/*: ^11.0|^12.0|^13.0 (or similar) rather than a hard pin. That constraint is the only thing 1.0.3 actually changes for most consumers.
• The package's config/*.php after publishing — that is the surface area you will actually touch day to day.
• The service provider's register()/boot() — tells you what is bound into the container, what is auto-discovered, and what routes/migrations/commands get registered behind your back.

First use case: wire it into one non-critical path (a single controller or a queued job) behind a config flag, run your existing test suite, and confirm nothing in the Laravel 13 upgrade path regressed before rolling it out.

If you are already on Laravel 11 or 12, there is no reason to rush this update unless you are moving to 13. If you are on Laravel 13 and were pinned to 1.0.2, this is a required upgrade.

Implementation Patterns

Pin the minor, let the major float. Use ^1.0.3 in composer.json. Because the change is a framework-constraint bump rather than an API change, you can safely run the same code on Laravel 11, 12 and 13 — which matters if you maintain multiple apps on different framework versions.

Resolve from the container, don't new it up. Bind-dependent construction goes through the container so config and any framework services are injected correctly:

public function __construct(private Vendor\Package\Client $client) {}

Use the facade only in views, Blade components, and quick tinker sessions; prefer constructor injection in jobs, listeners, and commands.

Isolate behind your own thin wrapper. Wrap the package in a small app-level service (App\Services\FooService) that exposes only the two or three methods you call. When the package changes again — or when you swap it — you change one class instead of grepping the codebase. This is the single highest-leverage pattern for a package whose changelog is one line long.

Queue the heavy work. Anything the package does that touches the network or the filesystem belongs in a job with $tries, $backoff, and failed() defined. Framework-major upgrades frequently shift how retry/timeout config is read, so keep those values explicit rather than relying on defaults.

Test against fakes, and assert on the wrapper. Use the package's fake/swap if it ships one (Package::fake(), Http::fake() if it wraps HTTP); if it doesn't, bind a mock in the container in your test's setUp(). Assert against App\Services\FooService, not against the vendor class, so your tests survive the next release.

Version matrix in CI. Since 1.0.3 claims multi-version support, add a small matrix (Laravel 12 + 13, lowest and highest dependency sets via composer update --prefer-lowest). This is the cheapest way to catch a constraint that lies.

Gotchas and Tips

• The changelog is one word. Verify the constraint yourself. composer show vendor/package and read the require block. A "Laravel 13" release sometimes ships the constraint but not the actual fixes, particularly around deprecations in the container, Str/Arr helpers, and the updated default database/session drivers.
• Auto-discovery vs. cached manifests. After upgrading, run php artisan package:discover (or composer dump-autoload). A stale bootstrap/cache/packages.php is the classic cause of "works locally, broken in CI."
• Config cache silently drops closures. If you publish the config and then add a closure or an env-dependent value that resolves at boot, php artisan config:cache in production will break it. Keep config values scalar and read env only inside the config file.
• Migrations are published, not run. If the package registers migrations, publishing copies them into database/migrations with a timestamp. On a long-lived project you can end up with duplicate migrations after a re-publish — check before committing.
• Facade vs. injected instance are not always the same object. If the package binds a non-singleton, state set via the facade won't be visible to the injected instance. Check bind vs. singleton in the provider if state seems to vanish.
• Laravel 13 deprecations surface as warnings, not errors. Run your suite with --fail-on-warning (PHPUnit 11+) or set a strict error handler so deprecated framework calls in the package don't silently pass until they become hard failures.
• Extension point: events and macros. Most packages fire events or are Macroable. Prefer listening to a package event or registering a macro over subclassing a vendor class — subclasses break on any internal refactor, and a one-line release is a good reminder that internals can move without ceremony.
• Debugging order of operations: config:clear → package:discover → check the provider is in bootstrap/providers.php (Laravel 11+ moved away from config/app.php) → php artisan about to confirm resolved versions. Nine times out of ten the problem is one of these four, not the package code.
• Rollback is cheap here. Since 1.0.3 changes a constraint rather than behavior, composer require vendor/package:1.0.2 is a safe revert if the Laravel 13 run misbehaves — provided you're not on 13, in which case you'll need a fork with a widened constraint via repositories in composer.json.