Pipedrive Laravel Package

Getting Started

Release 4.1.0 is a platform-compatibility release: the headline change is PHP 8 support. Nothing in the note signals new end-user APIs, so the first job is confirming your environment can consume it rather than learning a new feature.

Minimal steps:

1. Check your PHP version. php -v must report 8.0 or newer. If you're still on 7.4, stay on the 4.0.x line until your runtime is upgraded — this release is where the package's supported platform moves forward.
2. Confirm Laravel compatibility. Run composer why-not vendor/package 4.1.0 to see exactly which constraint (PHP, laravel/framework, or a transitive dependency) is blocking the upgrade before you touch composer.json.
3. Upgrade deliberately. composer require vendor/package:^4.1 --with-all-dependencies, then run your test suite and php artisan about to verify the resolved versions.
4. Where to look first. The package README and CHANGELOG.md for the 4.0 → 4.1 delta, then the package's composer.json (require block) to see the exact PHP and Laravel floors it now declares.

First use case: run your existing integration test that exercises the package's main entry point (a controller, job, or artisan command) on PHP 8 before deploying. That single smoke test tells you more about 4.1.0 than any changelog line, because the risk here is runtime behaviour on a new major PHP version, not API surface.

Implementation Patterns

Because 4.1.0 is a compatibility bump, the useful patterns are about adopting it safely rather than calling new methods.

• Treat the upgrade as a matrix problem. Add PHP 8.0 (and 8.1/8.2 if your host supports them) to your CI matrix alongside your current version. Run the same suite on both so a regression is attributable to the platform, not the package.
• Pin and stage. Use "vendor/package": "^4.1" in composer.json but commit composer.lock. Roll out to staging first; PHP 8 changes can surface in code paths your unit tests don't reach (serialization, error handling, locale/date formatting).
• Keep the framework constraint explicit. If you support multiple Laravel majors, constrain both axes (php and laravel/framework) so Composer doesn't resolve 4.1.0 on a Laravel version it wasn't tested against.
• Lean on Laravel's own PHP 8 readiness. Ensure you're on a Laravel release that officially supports PHP 8 before expecting the package to behave; a package that supports PHP 8 can still misbehave on an older framework that doesn't.
• Use config caching in the pipeline. php artisan config:cache and route:cache during deploy will catch service-provider registration problems introduced by a version bump far earlier than production traffic.
• Upgrade in a branch with a clean diff. Isolate the composer.json/composer.lock change so that if something breaks, you can bisect package resolution from platform changes.

Gotchas and Tips

• "Supports PHP 8" ≠ "requires PHP 8". Read the require block; the package may still support 7.4 and 8.0 simultaneously. Don't assume you're forced to upgrade your runtime.
• Deprecations are not failures — yet. PHP 8 promotes many notices to deprecations (optional-before-required params, ${var} string interpolation, passing null to non-nullable internals). Run your suite with error_reporting(E_ALL) and E_DEPRECATED visible so you see them before they become errors in PHP 9.
• Watch declare(strict_types=1) interactions. PHP 8 tightened comparison and type-juggling semantics (e.g. 0 == "foo" is now false, numeric string handling changed). Code that relied on loose coercion around package return values can silently change behaviour.
• --ignore-platform-reqs is a trap. It will let you install 4.1.0 on PHP 7.4 and then fail at runtime with confusing fatal errors. Fix the platform, don't bypass the check.
• Clear caches after upgrading. php artisan optimize:clear — stale compiled service manifests and cached config are the most common cause of "it installed but nothing works" reports after a version bump.
• Named arguments and constructor promotion are now available to you. If you're writing glue code around the package, PHP 8 lets you use named arguments against its public methods; be aware that parameter names become part of the contract, so don't rename them casually in your own wrappers.
• Debugging checklist when something breaks: composer why-not vendor/package 4.1.0 → composer show vendor/package → php artisan about → check the package's GitHub issue tracker filtered by the php-8 label. In that order; each step is cheaper than the next.
• Extension points unchanged (as far as this note indicates). No deprecations or removals are announced in 4.1.0, so any custom bindings, macros, or event listeners you've registered against 4.0.x should survive — but verify via a test rather than assuming, especially if you extend package classes whose signatures could have shifted for PHP 8 compatibility.