Cart Laravel Package

Getting Started

v2.0.0 is a compatibility release, not a feature release: the package itself gains Laravel 13 support, moves its test harness to Testbench v11 and Pest v4, and raises the floor to PHP 8.3. There is no new public API to learn, so "getting started" here means getting your environment onto the supported matrix before anything else.

Minimum steps:

1. composer require --dev the package at ^2.0, then confirm your platform: php -v must report 8.3.0 or newer and composer show laravel/framework must be 13.x (or your app must be willing to move).
2. Look first at the package's composer.json require / require-dev / conflict blocks and its phpunit.xml + tests/TestCase.php. Those three files tell you exactly which Testbench base class and which Pest bootstrap you need to mirror.
3. Run the package's own suite once before writing application code: vendor/bin/pest. If it is green, your toolchain matches what the maintainer validated.
4. First real use case: add one test of your own that extends the package's test case and exercises a single happy-path method. This is the cheapest way to discover whether you are on the Testbench v11 lifecycle (setUp/defineEnvironment) or the older one still.

If you are already on v1.x, treat the first step as "read the diff of the two composer.json files," not "read the changelog" — the changelog is one line and the diff is the real specification.

Implementation Patterns

Lockstep dependency bumps in your own composer.json. The release explicitly pairs Laravel 13 with Testbench v11 and Pest v4. Bumping one without the others is the most common failure mode. A safe pattern is to bump all three in a single commit so the lock file only has one resolution pass, then run the suite.

"require": { "php": "^8.3" },
"require-dev": {
    "laravel/framework": "^13.0",
    "orchestra/testbench": "^11.0",
    "pestphp/pest": "^4.0"
}

CI matrix aligned to the support floor. Because v2.0.0 drops PHP 8.2 and Laravel 12 and below, keep a matrix entry for the lowest supported combination (8.3 + Laravel 13) as well as the newest. A 8.2 job will now fail at composer install rather than at test time, which is a fast and unambiguous signal — let it fail loudly rather than pinning around it.

Package-development workflow via Workbench. With Testbench v11, the day-to-day loop is vendor/bin/testbench serve or vendor/bin/testbench workbench:build to boot a throwaway Laravel 13 app against your package. Use this instead of wiring the package into a real application when you are iterating on service-provider registration, config merging, or migrations.

Test-writing pattern under Pest v4. Register the base test case and any custom expectations once in tests/Pest.php, then keep individual test files to it()/test() declarations. If the package ships custom expectation macros, they belong in Pest.php's uses() block, not in each file — v4 resolves plugins earlier in the bootstrap and scattering registrations leads to "expectation not found" errors that only appear when running a subset of tests.

Integration tip: test the package against your app, not just itself. Keep one integration test in your application that boots the package's service provider for real (not via Testbench) and asserts a container binding resolves. Testbench-based package tests run in a synthetic app that can drift from your real bootstrap; the pairing catches provider ordering and config-publishing regressions that unit-level package tests miss.

Upgrade-in-place workflow. For an existing v1.x integration: create a branch, bump PHP constraint, run composer update --with-all-dependencies, run the suite, and only then start fixing failures. Sorting failures into "my code" vs "Pest v4 test-syntax" vs "Testbench v11 lifecycle" before touching anything saves a lot of churn.

Gotchas and Tips

• This is a silent-ish break for old environments. There are no deprecation warnings for someone on PHP 8.2 or Laravel 12 — Composer simply refuses the upgrade. If you see an inexplicable "package requires php ^8.3" resolution error, that is the release, not a broken lock file.
• Pest v4 is the likeliest source of upgrade pain, not Laravel 13. Expect breakage in custom plugins, removed/deprecated expectation chains, and dataset syntax. Run the suite with --filter on a single file first to isolate whether a failure is Pest-syntax or genuine logic.
• Testbench v11 lifecycle changes hide in setUp. The classic symptom is $this->app being null or a config value not applied. Check whether you are overriding setUp() vs using defineEnvironment()/defineDatabaseMigrations() hooks — the latter are resolved at a different point in the boot sequence and are the supported path.
• phpunit.xml schema drift. Testbench/Laravel bumps frequently move attributes or drop --configuration-level options. If PHPUnit warns about unknown attributes, do not ignore it; those warnings become hard failures on the next minor.
• Parallel testing needs brianium/paratest. pest --parallel in v4 requires the paratest dependency declared explicitly. If --parallel silently runs serially, that dependency is missing rather than the flag being broken.
• Debugging a single package test: vendor/bin/pest --filter="the test name" --stop-on-failure. If the failure only appears in the full suite, suspect shared application state in Workbench rather than test ordering.
• Extension points unchanged, but verify: config keys, container bindings, and published assets should be identical to v1.x. Since the release notes contain no API changes, anything that behaves differently after the upgrade is a genuine regression and worth an issue — do not assume it is intended.
• Pin orchestra/testbench narrowly (^11.0) rather than allowing >=11. Testbench minors have a history of adjusting the base test case, and a floating constraint can turn a green pipeline red without any change on your side.
• Keep a compatibility note in your README stating PHP 8.3+ / Laravel 13+ / Pest v4. Consumers on 8.2 will otherwise open issues against a package that cannot support them.