Tmp Storage Bundle Laravel Package

Getting Started

v0.6.3 is a compatibility release, not a feature release: dependency constraints were widened/raised for Symfony 8 and PHP 8.4. There are no new APIs to learn, so the "getting started" work is mostly verifying that the package resolves and boots on your target platform before you build on it.

First steps:

1. Check the floors before installing. The package now expects PHP 8.4 and Symfony 8. If your app is pinned to Symfony 6/7 (typical on older Laravel releases), v0.6.3 may not install at all — or may force a wider upgrade than you intended.

composer require vendor/package:^0.6.3
composer show vendor/package          # confirm the resolved version
composer show symfony/*               # confirm which Symfony line actually won
composer why-not vendor/package 0.6.3 # if it refuses, this tells you who's blocking

2. Read composer.json first, then the README. For a 0.x package the require / require-dev block is the real contract — it tells you the minimum PHP, the Symfony component split, and which Laravel versions the maintainer actually tests against.

3. Find the service provider. Look in src/ for a *ServiceProvider (and a Facade/ directory if one exists). That file is your map of what gets bound into the container — manager classes, drivers, HTTP clients, console commands, and which config keys are read. Anything you need to override later, you override there.

4. Publish and read the config.

php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"

The published config file is usually the fastest inventory of the package's behaviour — drivers, endpoints, timeouts, queue names.

5. First real use case: wire it into a single, low-risk code path (one job or one controller method), not the whole app. Confirm on PHP 8.4 that the container resolves, config loads, and the happy path works. Only then spread it.

If you're already on an earlier v0.6.x, treat this as a patch bump but upgrade with -W so Composer can actually move the Symfony deps:

composer update vendor/package -W

Implementation Patterns

Treat the package as an implementation detail, not a framework. At 0.x with a dependency-floor bump, the highest-value pattern is a thin adapter you own:

// app/Contracts/Thing.php
interface Thing { public function run(array $payload): Result; }

// app/Services/PackageThing.php
final class PackageThing implements Thing
{
    public function __construct(private \Vendor\Package\Manager $manager) {}

    public function run(array $payload): Result
    {
        return Result::fromArray($this->manager->execute($payload));
    }
}

// app/Providers/AppServiceProvider.php
$this->app->bind(Thing::class, PackageThing::class);

When v0.7 renames a method, you edit one file and your controllers/tests don't move.

Let Laravel own the Symfony version. Don't pin symfony/* yourself to "help" the package resolve. Add the package and let your laravel/framework constraint drive the Symfony line; if Composer can't find a solution, that's real information about your app's floor, not a problem to paper over with a manual pin.

Config over constructor arguments. Pass behaviour through config('package.*') (env-backed), not through hardcoded values at call sites. This keeps the package mockable and lets you flip drivers per environment without a redeploy of code.

Queue and HTTP boundaries. If the package makes outbound calls or dispatches work, wrap the entry point in a job with $tries/$backoff and a timeout. A dependency bump can change the underlying HTTP client's default timeout (Symfony's HTTP client has its own defaults) — set them explicitly in your job rather than relying on the package's defaults.

Testing pattern: bind a fake of your own Thing interface in feature tests and only exercise the package adapter in a single integration test tagged @group external. That way a Symfony upgrade breaks one test, not the suite.

// tests/Feature/ThingTest.php
$this->mock(Thing::class, fn ($m) => $m->shouldReceive('run')->andReturn($result));

CI matrix. Since this release is explicitly about version support, mirror it: run PHP 8.4 + highest deps on one job and PHP 8.4 + --prefer-lowest on another. --prefer-lowest is what catches a too-narrow constraint that the maintainer missed.

Gotchas and Tips

• 0.x semver means minors can break. ^0.6 is safe-ish only up to 0.7.0; Composer treats 0.x minors as potentially breaking, and you should too. Commit the lock file and review the diff of composer.lock on every bump — it's the only place the Symfony version change is visible.
• "Supports Symfony 8" ≠ "requires Symfony 8". A widened constraint means the package can resolve against 8, but if your app pulls Symfony 7 the package will install on 7 and take a different code path than the maintainer tested. Verify with composer show symfony/* after installing and, ideally, run your app's test suite — not just the package's.
• PHP 8.4 deprecations surface as noise, then bugs. Implicit-nullable parameters and property hooks-adjacent deprecations are the common offenders in older Symfony integrations. Run your suite with deprecations escalated to errors in CI to find them; otherwise they'll only appear in production logs.
• Conflict resolution deadlock. If another package pins symfony/console:^6 (or an old Laravel), you'll get an unsolvable set. composer why-not names the culprit. The fix is usually upgrading that package, not downgrading this one — but sometimes the correct call is staying on v0.6.2 until your framework floor moves.
• Don't subclass package internals. With a 0.6.x package, extends on anything not documented as an extension point is a future break. Prefer: config overrides → container rebinding → decorator around the package's interface → (last resort) fork.
• Extension points to check in src/: constructor bindings in the service provider (swap implementations via $this->app->bind), config keys (usually the intended knob), events dispatched by the package (hook instead of patching), and any Illuminate\Contracts interfaces you can implement yourself.
• No changelog entry for behaviour changes is a signal. Releases that only touch composer.json rarely regress, but confirm by diffing src/ between tags rather than trusting the message:

composer diff vendor/package 0.6.2 0.6.3   # or: git diff 0.6.2..0.6.3 -- src/

• Pin CI to a real Laravel + Symfony pair. Testing this package on a Laravel version you don't run in production gives false confidence; the container wiring and the Symfony line both shift with the framework.
• Watch for a 1.0 signal. A dependency-floor raise at 0.6.x often precedes a stable release. If you're adopting the package heavily, ask the maintainer whether the public API is expected to freeze — that determines whether your adapter layer is temporary insurance or permanent architecture.