Pomm Bundle Laravel Package

Getting Started

This release is a major-version jump (3.0.0) and the headline is a platform shift, not a feature: the package now targets Symfony 5 only, dropped Symfony 2, and dropped PHP 5.

For a Laravel developer, the first thing to establish is whether this package is even consumable in your app. If it's a Symfony bundle, it is not a Laravel package and you won't be able to composer require it into a typical Laravel app without pulling in symfony/framework-bundle and wiring a kernel by hand. Check composer.json before anything else:

1. Read the require block. Look for symfony/* constraints and the php constraint. Anything pinned to ^5.0 means the code relies on Symfony 5 APIs that Laravel does not ship.
2. Check for a Laravel service provider. If there's no *ServiceProvider with Illuminate\Support\ServiceProvider and no config/ publish tag, this is not a Laravel-native package — plan on using the underlying classes directly or skip it.
3. Confirm your Laravel version's Symfony floor. Laravel 7.x and 8.x ship Symfony 5 components, so the new constraint is satisfiable. Laravel 5.x/6.x ship Symfony 4.x and cannot install 3.0.0. This is the single most likely reason your composer update fails.
4. If it's a standalone library (no framework coupling beyond the Symfony components), the practical entry point is the top-level class or facade-ish entry in src/, plus the tests directory — the tests are the best documentation for the 3.0 API.

First use case: pin the version and prove the install. Run composer require vendor/package:^3.0 --dry-run first — it resolves constraints without touching vendor/ or composer.lock, so you learn about a Symfony 5 conflict in seconds instead of after a broken install. If it resolves, instantiate the primary class in php artisan tinker and exercise one read-only path before writing any integration code.

If you're on Laravel 6 or older, stay on the 2.x line and treat 3.0.0 as blocked until you upgrade Laravel. That's a project-planning decision, not a code decision.

Implementation Patterns

Pin the major version explicitly. With a 3.0.0 that drops two platforms, floating constraints are dangerous. Use "vendor/package": "^3.0" rather than "*" or "dev-master", and commit composer.lock. If the package is shared across apps on mixed Laravel versions, that lock file is the only thing keeping the PHP 5 drop from surfacing as a fatal in production.

Isolate the package behind your own adapter. Because the 3.0 line is coupled to Symfony 5, treat it as an implementation detail. Define a small interface in your app (App\Contracts\...), bind a concrete implementation in a service provider, and let only that one class import the vendor namespace. When Symfony 6 or a 4.0 release lands, you change one file. This also gives you a seam for faking the dependency in tests.

Bind it as a singleton. Most Symfony-derived services are stateless-but-expensive to construct. In AppServiceProvider::register(), $this->app->singleton(Adapter::class, fn () => new Adapter(new VendorClient(...))). Inject the interface, never new it inline — constructor injection is what makes the upgrade to 4.0 a one-line change.

Feature-detect, don't version-sniff. If you support both 2.x and 3.0 across apps, don't branch on composer.json contents at runtime. Wrap the differences in your adapter and use method_exists() / interface checks. The 3.0 release notes describe removals, not replacements — assume any Symfony-2-era API you were leaning on is simply gone, and let a failing test tell you where.

Run the package's own test suite once, locally. Before trusting 3.0 in your app, clone it and run composer install && vendor/bin/phpunit against your PHP version. A major release that only removes platforms sometimes ships with a CI matrix that skipped your exact PHP minor. Ten minutes here beats debugging a silent behavioural change later.

Integrate via queued jobs for anything slow. If the package does I/O (HTTP, filesystem, external service), call it from a job rather than a controller or a model observer. This is standard Laravel hygiene, but it matters more here: you can't easily instrument third-party internals, so isolating the call site makes retries, timeouts, and failure logging yours to control.

Test with a contract test, not mocks of vendor classes. Write one test that runs against the real adapter and asserts your expected input/output shape. Mocking deep vendor internals couples your tests to the exact 3.0 API and makes the next major upgrade a test-rewrite project.

Gotchas and Tips

The PHP 5 drop is a hard floor, and the notes don't say what replaced it. The release notes say "removing support for php5" but not the new minimum. Read the php constraint in composer.json — it's likely 7.2.5+ to match Symfony 5. Your CI matrix and any legacy container images need to clear that bar, and composer install will fail loudly rather than degrade gracefully. Check your deploy images before your local environment; production is where this bites.

Symfony 5 support means Laravel 7+ in practice. This is the gotcha most likely to cost you a day. The error surfaces as an unresolvable dependency chain mentioning symfony/* conflicts, which reads like a Composer problem rather than a framework-version problem. Don't try to force it with --ignore-platform-reqs or --with-dependencies gymnastics; if you're on Laravel 6, the answer is no.

Confirm what "removing support for sf2" actually removed. Dropping a platform sometimes means deleting the compatibility shims that made older APIs work. Any code of yours that reached into Symfony-2-era classes or relied on deprecation-layer behaviour will now fail with a class-not-found rather than a deprecation notice. Grep your codebase for vendor namespace references outside your adapter before upgrading.

No Laravel service provider means no auto-discovery. If you expected config/package.php publishing or a facade, it isn't coming. You'll wire configuration yourself through config/services.php or a dedicated config file, and you'll construct the client manually in a provider. Budget for that; it's the difference between "install and go" and "half a day of wiring."

This is a removal-heavy release with no new features. That's a good sign for stability but means there's no functional reason to upgrade — the only reasons are security support and staying current with Symfony. If you're on 2.x and it works, upgrading is a maintenance decision, not a value decision. Schedule it; don't rush it.

Debug at the boundary. When calls into the package misbehave, you can't easily step through vendor code. Log the adapter's inputs and outputs and the elapsed time, and set APP_DEBUG behaviour aside — third-party exceptions won't render helpfully. Wrap calls in try/catch and rethrow as a domain exception so your handler and logs stay coherent.

Extension points are likely thinner than 2.x. Major releases that remove platform support often drop the pluggable interfaces that existed purely to abstract over Symfony 2. Check whether the interface you were implementing still exists before porting customisations. If it's gone, your extension logic has to move into your adapter layer.

Pin dev dependencies separately. If this package is in require-dev (test helpers, fixtures), the PHP floor still applies to CI even though it never ships. Don't let a dev-only constraint quietly break your build on an older runner image.