Lib Lock Bundle Laravel Package

Getting Started

Start by pulling the package in and letting Composer tell you what it actually brings along:

composer require <vendor>/<package>:^2.2
composer show --tree <vendor>/<package>

As of 2.2.1 that tree is noticeably leaner — symfony/console is gone from require and symfony/yaml is now require-dev only. Read the resulting composer show --tree output before writing any code; it tells you exactly which transitive Symfony pieces you can no longer lean on implicitly.

Then look at three files in this order:

1. The package's composer.json (what's a runtime dependency vs. dev-only — this is where 2.2.1 changed the contract)
2. The service provider — what it binds, whether it's deferred, what it publishes
3. The public entry point (facade or main class) — the surface you'll actually call

If the provider registers publishable assets:

php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"

A good first use case is the smallest possible round-trip: resolve the package out of the container in php artisan tinker, feed it a config array or a file path, and confirm you get an object/value back. That validates provider registration, config merging, and the dependency situation in one shot — before you wire it into a job or a controller.

Implementation Patterns

Wrap it in an application-level adapter. The 2.2.1 release is a reminder that this package's dependency graph is not stable. Don't call the package directly from twenty controllers; put a thin App\Support\... class or a small interface in front of it. When the next release drops another dependency or renames a method, you change one file.

Constructor injection over facades. Resolve the package (or your adapter) through the container. If the provider is deferred this keeps the cost off requests that don't touch it:

final class ImportSettings
{
    public function __construct(private PackageContract $package) {}

    public function load(string $path): array
    {
        return $this->package->parse($path)->toArray();
    }
}

Config-driven setup. Publish the config and keep environment-specific values in config/ rather than in call sites. Reference them via config('package.key') so config:cache works — never read env() from inside the package's config at runtime.

Testing with Testbench. orchestra/testbench gives you a real Laravel container in a package test. Because symfony/yaml is a dev dependency now, it is available in your require-dev test suite — so use it to build fixtures, but never let a fixture helper leak into production code paths.

Queue and console contexts. If your usage lives inside a job, make sure the adapter is serialisable or resolved in handle(). Anything that previously reached for console output helpers should now use Log or an injected OutputStyle you supply yourself.

Gotchas and Tips

The 2.2.1 changes are dependency-level breaking changes even though no API moved. Two concrete failure modes:

• symfony/console removal. If your code (or a wrapper you wrote around this package) used Symfony\Component\Console\Command\Command, CommandTester, OutputInterface, or table/helper classes and was getting them transitively, it will now fail to autoload. Add symfony/console to your composer.json explicitly. Grep for Symfony\Component\Console before you deploy.
• symfony/yaml moved to require-dev. This is the sharper edge. In development everything works, composer install --no-dev on the deploy target breaks with Class "Symfony\Component\Yaml\Yaml" not found. This bites hardest when YAML is used for runtime config, translation imports, seeders, or fixture loading in staging. If any production code path touches YAML, you must declare symfony/yaml in your own require block.

Diagnose with Composer, not the stack trace. composer why symfony/yaml and composer why-not symfony/yaml answer "who still wants this" and "why can't this upgrade" faster than reading a fatal error.

Always dry-run before deploying: composer update --dry-run <vendor>/<package> — dependency-only releases are exactly the ones where a silent transitive removal slips through CI if your build caches vendor/.

Pin the minor, not the patch: use ^2.2 in composer.json but commit composer.lock. A 2.2.x that shuffles require blocks is not a release you want auto-applied on every deploy.

CI check worth adding — run your test suite once with composer install --no-dev (or at least composer check-platform-reqs) so dev-only dependency assumptions surface before production does.

Caching: if you wrap package output in Cache::remember, key on the input file's mtime or hash. Dependency shuffles don't change behaviour of cached values, but they do change what gets rebuilt after a deploy — stale keys will mask the real problem during a rollback.

Extension points remain the safe surface. Prefer published config, container bindings, and any documented interfaces over extending package internals. Internals are what move when a maintainer trims require blocks; the published config and the public entry point are the parts they're implicitly promising to keep.