Lib Lock Bundle Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel/PHP majors). Removing symfony/console from require eliminates one of the more common Composer deadlocks: laravel/framework pins its own symfony/console range, so any third-party package declaring it directly can block a Laravel major upgrade until the vendor ships a fix. This release lowers the odds that this package becomes the reason an upgrade sprint slips.
• Build vs buy / dependency posture. A smaller hard dependency set means fewer transitive CVEs to track, faster CI and image builds, and less security-review surface for teams with a supply-chain checklist. If this package was previously flagged in a dependency audit for pulling console tooling it never used at runtime, that flag can likely be cleared.
• Runtime capability scoping. symfony/yaml moving to require-dev tells you the YAML path is no longer a supported production capability — it is test/tooling-only. If any roadmap item assumed this package could read or author YAML config, fixtures, or definitions in a deployed environment, that assumption needs re-checking before it lands in a spec.
• Patch-level upgrade decision for this sprint. This is a low-risk version bump to schedule into routine maintenance, conditional on a five-minute verification that nothing in production touches the YAML path. Treat it as a maintenance ticket, not a feature release — no roadmap items should be waiting on 2.2.1.

When to Consider This Package

Adopt when:

• The package's core value is in code paths that don't depend on YAML at runtime — verify against your own usage before committing.
• You are on, or approaching, a Laravel major upgrade and want to shrink the set of packages that can constrain symfony/* versions.
• Your dependency policy penalises unnecessary hard requirements, or you run automated license/CVE gates that benefit from a leaner graph.

Look elsewhere / hold when:

• Your integration relies on YAML-driven configuration, fixtures, or definitions at runtime. A require-dev move is a silent capability removal at patch level — semver says 2.2.1 is safe, but if your code called that path, it will fail at deploy, not at composer update. Confirm against the changelog and the package's own docs before upgrading; if the docs still advertise YAML support, treat that as a documentation defect and raise it upstream rather than absorbing the risk.
• The package's README or config examples still show symfony/yaml as a runtime expectation — that mismatch is a signal about release discipline worth weighing for anything you'd put on a critical path.
• You need a formal deprecation window for removed behaviour; this release did not provide one.

How to Pitch It (Stakeholders)

To executives: A small, housekeeping release — the vendor removed a heavyweight dependency the package didn't need and moved a second one to development-only. Net effect is a lighter, easier-to-audit dependency footprint and one fewer thing that can stall a future Laravel upgrade. No new functionality, no user-facing change, no cost. Approve as routine maintenance.

To engineering: Schedule the bump as a low-priority ticket. Two things to check first: (1) grep for YAML usage — if any production path parses or emits YAML through this package, that capability is now unsupported and the upgrade is effectively breaking despite the patch version; (2) confirm your lockfile resolves cleanly, since a dependency removal can shift shared transitive versions. If either check surfaces a problem, pin to the prior minor and raise it upstream. Otherwise this is a straightforward win on dependency hygiene and Composer headroom for the next framework upgrade.