Js Routing Bundle Laravel Package

Product Decisions This Supports

• Framework-vendor alignment (Symfony 6/7, PHP 8): Confirms the package is tracking upstream support windows, which lets you keep the app on supported runtimes without pinning legacy versions — a prerequisite for any roadmap item that requires modern PHP features.
• Build vs. buy: The v5.0.0 restructure (bundle class now owns configuration, directories reorganized) signals a package converging on Symfony's idiomatic bundle conventions. That strengthens the "buy/integrate" case versus maintaining an in-house fork, but only if your integration surface is config-driven rather than reaching into internal paths.
• Migration scoping: Directory restructuring plus PHP 8 constructor promotion in classes are source-level breaking changes for anyone extending or decorating the package's classes. This directly sizes a sprint of upgrade work (subclass fixes, config key remapping, DI wiring) that must be scheduled against other roadmap commitments.
• Use cases supported: Suitable for Laravel/Symfony hybrid stacks, packages consumed by both frameworks, or apps that need bundle-style configuration loading. Less relevant for pure Laravel-only apps that never touch the Symfony container.
• Release hygiene as a signal: The release notes explicitly flag "Need to fix up mock objects in tests" — an acknowledged incomplete test suite. This is a product-risk input: adopt behind a feature flag or in a non-critical service until a follow-up patch lands.

When to Consider This Package

Adopt when:

• You are on, or actively migrating to, Symfony 6/7 and PHP 8+; v5.0.0 is the version that actually supports that matrix.
• Your codebase consumes the package only through its public configuration surface (bundle class, config files). If so, the directory restructure is largely invisible to you and upgrade cost is low.
• You are starting fresh rather than mid-freeze — a major version with reorganized internals is cheaper to absorb on a new integration than retrofitted into a release candidate.
• You need bundle-style configuration semantics in a codebase shared with Symfony tooling.

Look elsewhere or defer when:

• You are pinned to Symfony <6 or PHP <8 — v5.0.0 is not for you and v4.x is now a maintenance tail you must plan an exit from.
• You extend, subclass, or monkey-patch package internals; the restructure plus constructor-promotion changes will break you, and the acknowledged test/mock gaps mean regressions may not be caught upstream.
• You require a stable, fully verified test suite as an adoption gate — the release itself admits mocks are unfixed. Wait for v5.0.x.
• The package is a transitive dependency you don't control: check whether any dependent package has declared Symfony 6/7 support yet, or you'll create a version conflict.

How to Pitch It (Stakeholders)

For executives: A new major version (v5.0.0) brings this package current with Symfony 6/7 and PHP 8 — the supported, security-patched runtime generation. Staying on the prior version means running on frameworks approaching end-of-support, which is a compliance and security exposure, not just a technical preference. Cost is a bounded upgrade task, not a rewrite, provided we haven't customized the package's internals; engineering needs a short spike to confirm that.

For engineering: This is a breaking major. Three things move: directory layout, configuration ownership (now via the bundle class), and class constructors (PHP 8 promotion). Any subclass, decorator, service override, or hardcoded internal path is a break. Config keys and package.json/tooling references were regenerated via cook, so diff your published config against the new defaults rather than assuming parity. Treat the upstream note about unfixed test mocks as a real risk: pin to ^5.0 only after smoke-testing our integration path, and be prepared to carry a local patch or contribute the mock fixes upstream. Recommend a timeboxed spike to inventory our touchpoints before committing to a migration date.