Autowire Laravel Package

Getting Started

• Confirm your app meets the 3.0 requirements before installing: this release drops EOL PHP and Laravel versions, so you need a currently supported PHP/Laravel combination (and Laravel 13 is now explicitly supported). Check composer.json constraints and run composer why-not vendor/package 3.0 if the upgrade is blocked.
• Install/upgrade with composer require vendor/package:^3.0 (or composer update vendor/package --with-dependencies). Because this is a major bump, review the diff in your composer.lock and run the full test suite immediately after upgrading.
• First place to look: the package's README and config/ file (if published). The headline 3.0 feature for day-to-day use is the WithCachedAutowire trait, so start by applying it to your base TestCase.
• Minimal first use case: add the trait to tests/TestCase.php and run a representative slice of your test suite. This is the lowest-risk way to validate that cached autowiring works with your service provider graph before rolling it out across the whole suite.

// tests/TestCase.php
use Vendor\Package\Testing\WithCachedAutowire;

abstract class TestCase extends BaseTestCase
{
    use WithCachedAutowire;
}

• If your team uses Laravel Boost, install/enable the newly shipped Boost skill so AI-assisted workflows can discover the package's conventions. Look for the skill in the package's boost/ or documented install command rather than guessing.

Implementation Patterns

• Test-suite acceleration as the default pattern. Put WithCachedAutowire on the base TestCase so every feature/unit test benefits. For suites with wildly different container needs, apply it selectively on test classes or a shared CachedContainerTestCase base instead of globally.
• Pair with RefreshDatabase / DatabaseTransactions carefully. The trait caches container resolution; if a test mutates bindings (e.g. $this->app->bind(...) or instance() swaps), reset or avoid the cache for that class. A common pattern is a small base class for tests that need fresh bindings and the cached base for everything else.
• Mocking workflow. Bind mocks in setUp() before the first resolution that exercises the cached path. If you use $this->mock() / $this->partialMock(), verify the cached autowire result still reflects the mock—if not, resolve those dependencies through the container after binding or disable caching for that test.
• CI integration. Run the suite once with the trait enabled and once without (or on a canary job) after upgrading to 3.0. This catches container-graph assumptions that only surface under caching. Keep the non-cached run as a diagnostic job if your suite is fast enough.
• Laravel 13 readiness. If you're planning the Laravel 13 upgrade, this release lets you keep the package in the dependency tree. Use it as part of a staged upgrade: bump Laravel, bump this package to ^3.0, then run the cached-autowire test suite as an integration smoke test for the container changes Laravel 13 introduces.
• Laravel Boost skill. Wire the skill into your Boost setup so package-specific guidance is available in AI-assisted code review and scaffolding. Treat it as documentation-in-tooling: useful for onboarding, but still validate generated code against your app's actual provider graph.

Gotchas and Tips

• Major-version upgrade: 3.0 removes EOL PHP and Laravel support. If you're on an older PHP/Laravel, you cannot take this release—plan the platform upgrade first. Check transitive dependency conflicts before assuming a simple composer update will work.
• Cached autowiring changes test isolation semantics. Tests that previously passed because the container re-resolved fresh instances may now see cached ones. If a test starts leaking state, look for bind/singleton/instance mutations in setUp() and either reset the container or exclude that test from the cached path.
• Debugging cache surprises: when a dependency resolves unexpectedly, temporarily remove the trait from the base TestCase and re-run the failing test. If it passes without the trait, the issue is cache lifetime, not your binding logic.
• Don't cache around dynamic config. Tests that change config() between cases and rely on container re-resolution (e.g. drivers, mailers, filesystems) are the most common source of flakiness. Set config before the app boots, or use a non-cached base class for those tests.
• Laravel Boost skill availability varies by Boost version. If the skill doesn't appear, check your Boost installation and the package's documented discovery path; don't assume the skill ships in every installation mode.
• Extension point: keep your own base TestCase thin. Wrap the trait behind a project-specific base class so you can swap caching behavior, add resets, or disable it for specific test groups without touching every test.
• Pin and document the upgrade. Record the 3.0 upgrade (PHP/Laravel minimums, trait adoption) in your project's upgrade notes so future contributors know why the test base class uses cached autowiring and when to opt out.