Youtube Laravel Package

Getting Started

Check your runtime first. v2.2.6 drops PHP 7 support, so the package now requires PHP 8.0+. Before anything else:

php -v
composer why-not vendor/package 2.2.6   # shows what's blocking the upgrade
php -l && composer update vendor/package --with-dependencies

If you are still on PHP 7.4 anywhere — a legacy service, a Docker base image, a CI matrix entry, a shared platform config in composer.json — pin to the last v2.2.x that supported it and plan the runtime upgrade separately. Note that config.platform.php in composer.json will silently hold you back even on a PHP 8 machine; check it explicitly.

Where to look first. Since this is a maintenance release with no new API surface, start with the package's CHANGELOG.md and the diff between the previous tag and v2.2.6 rather than the docs. Confirm that nothing beyond the PHP constraint and dev dependencies changed. Then read the service provider to see what is auto-registered and which config keys are published — that tells you the real integration surface faster than the README.

First use case. Install, publish config if the package exposes it, and wire up the smallest end-to-end path in a throwaway test or Tinker session:

composer require vendor/package:^2.2
php artisan vendor:publish --provider="Vendor\Package\ServiceProvider"
php artisan tinker

Call the package's primary entry point once, confirm the result, then delete the scratch code. That single round trip validates autoloading, config resolution, and container bindings in one go.

Implementation Patterns

Pin the constraint, not the version. Use ^2.2 (or ~2.2.6 if you need to be strict) so patch releases like this one flow in via composer update without a lockfile bump review every time. Given the release history is patch-level and non-breaking, a caret constraint is the right default.

Resolve through the container, not new. Bind the package's client/manager in a small app-level service provider and inject it. This is what makes the eventual major version (where constructors and config keys tend to move) a one-file change instead of a grep across the codebase.

$this->app->singleton(PackageClient::class, fn ($app) => new PackageClient(
    config('package.api_key'),
    config('package.endpoint'),
));

Wrap calls in your own thin adapter. Even a five-method class that delegates to the package gives you a seam for tests and for swapping implementations later. Day-to-day this pays off when you need to add retries, logging, or tenancy scoping — you add it in one place rather than at every call site.

Keep config in config/package.php, secrets in .env. Use env() only inside the published config file, never in application code — otherwise config:cache in production will return null for values that worked in local development.

Test against the package's own conventions. This release updates PHPUnit to the latest version. If your test suite touches the package's testing helpers or fakes, align on modern PHPUnit idioms: #[Test] and other attributes instead of @test/@dataProvider docblock annotations, and static data providers. Do this proactively even if your own suite is still on PHPUnit 9 — it keeps you from being blocked when you eventually bump.

CI matrix. Drop 7.x from your matrix in the same pull request as the version bump, and add 8.2/8.3 if they are missing. A matrix that still lists 7.4 will fail on install, not on tests, which is a confusing failure mode to debug.

Gotchas and Tips

The PHP constraint is transitive. The package's own composer.json now requires PHP 8+, and that constraint propagates through your dependency graph. A package you depend on that still allows 7.4 is irrelevant — but your root require.php and config.platform.php are both hard gates. If composer update reports "your requirements could not be resolved," check platform before you start reading dependency trees.

No application-facing breaking changes — but verify. Dropping PHP 7 and bumping PHPUnit are both non-runtime changes for consumers on PHP 8. There is no deprecation of public API implied here. Do a quick git diff previous-tag..v2.2.6 -- src/ to confirm the source tree is untouched; if it is empty, the upgrade is a pure constraint change and safe to ship without a full regression run.

PHPUnit upgrades bite in dev, not prod. If your suite extends the package's test case or uses its fakes, a PHPUnit major bump can change assertion signatures, mock defaults, and how deprecations are reported. Symptom: tests pass in isolation and fail in the full run, or risky warnings appear that were not there before. Run the suite once with --display-deprecations after bumping.

Watch for config default drift. Patch releases occasionally adjust a default value inside the published config. Since vendor:publish will not overwrite your existing file, compare config/package.php in your app against the package's version after upgrading:

diff config/package.php vendor/vendor/package/config/package.php

Cache clearing is not optional. After any package upgrade, run php artisan config:cache (or config:clear in local) and php artisan package:discover. Stale cached config plus a new package version produces errors that look like bugs in the package but are just old values in bootstrap/cache/config.php.

Extension points to prefer. Service provider bindings, published config, and any published migrations or views are the stable extension surface. Avoid overriding package classes via class_alias or reflection — these are the things that break silently across patch releases and are invisible in code review.

Lockfile discipline. Commit composer.lock for applications (not for libraries). When you take v2.2.6, the lockfile diff should show only the package and its dev tooling — if unrelated packages move, your constraint graph is loose somewhere and the upgrade is not as isolated as it appears.