Nav Bundle Laravel Package

Technical Evaluation

Architecture fit The v2.0.0 release notes describe a Symfony-oriented package (removal of easycorp/easyadmin-bundle and sensio/framework-extra-bundle support, adoption of symfony/phpunit-bridge, and a symfony ^6.0 constraint). This is inconsistent with the stated framing of a "Laravel/PHP package." Before any integration decision, confirm what this package actually is. Two scenarios:

• Symfony-first package: the release is a normal modernization (PHP 8 + Symfony 6), and it is a poor architectural fit for a Laravel codebase unless consumed as a framework-agnostic library.
• Laravel package with Symfony dev/optional dependencies: the removals are largely test-tooling and optional-integration cleanup, and fit is neutral-to-positive.

No evidence in this release of Laravel-specific integration surfaces (service provider, facade, config publishing, Artisan commands). Absent those, treat it as a standalone PHP library, not a Laravel package.

Integration feasibility Feasible on PHP 8 with Symfony 6 components. Two hard blockers exist for existing consumers: (1) any code path relying on the EasyAdmin or SensioFrameworkExtraBundle integrations is removed outright, with no stated deprecation shim; (2) the new PHP 8 and Symfony 6 floors eliminate PHP 7.x and Symfony 5 environments. Where neither removed integration is in use, the upgrade surface is small — the remaining changes are tooling (PHPUnit bridge, CS, PHPStan) and should be behavior-neutral.

Technical risk

• High: silent breakage for anyone using the removed integrations — these are [BC] removals in a major bump, so breakage is expected but the blast radius is undocumented.
• Medium: transitive dependency conflicts. Symfony 6 constraints can collide with illuminate/* component versions in older Laravel releases; the release notes make no compatibility statement about Laravel.
• Low: static analysis and CS fixes; the PHPUnit bridge migration affects only the package's own test suite, not consumers.
• Unknown: whether the removed Symfony coupling makes the package more framework-agnostic (a potential upside for Laravel use) or simply narrows it further toward Symfony 6.

Key questions

1. Is this package genuinely intended for Laravel, or is the "Laravel/PHP" framing inaccurate? What does its composer.json declare?
2. Do any of our applications use the EasyAdmin or SensioFrameworkExtraBundle integrations being removed?
3. What are our current PHP and Symfony component versions, and what Laravel version(s) must we support?
4. Is v1.x still receiving security/maintenance patches, and for how long?
5. Does v2.0.0 reduce or increase Symfony coupling — is a Laravel adapter planned or out of scope?

Integration Approach

Stack fit Conditional. On a Symfony 6 / PHP 8 stack, fit is good and the release modernizes an already-aligned package. On a Laravel stack, fit is unproven: no Laravel-native integration is evidenced, and the package's center of gravity is Symfony. Do not plan an integration until the framework question above is resolved.

Migration path

1. Inventory usage of EasyAdmin and SensioFrameworkExtraBundle across our codebase.
2. If either is in use, stay pinned to v1.x and open an upstream issue or plan an internal replacement before upgrading.
3. If neither is used, upgrade to v2.0.0 as a routine major bump, gated on PHP 8 and Symfony 6 availability.
4. If the package is being evaluated fresh for a Laravel app, treat v2.0.0 as a new dependency and run a spike rather than a migration.

Compatibility Hard floors: PHP 8.0+ and Symfony ^6.0 component constraints. The EasyAdmin and SensioFrameworkExtraBundle integration paths are gone in v2. Laravel compatibility is undocumented in this release and must be validated empirically via composer why-not / dependency resolution against the target Laravel version.

Sequencing Resolve the framework-identity question first — it gates everything else. Then run the usage audit for removed integrations, then upgrade the runtime (PHP 8, Symfony 6) in a branch, then bump the package. Do not sequence the package bump ahead of the runtime upgrade; the constraints make that order impossible.

Operational Impact

Maintenance Positive signals: PHPStan fixes, CS normalization, and migration to the maintained symfony/phpunit-bridge indicate an actively tended codebase. The cost is a major version event requiring consumer-side work. Track upstream for guidance on v1.x support duration.

Support No stated LTS or backport policy. The removal of two integrations in a single major release without a deprecation cycle raises a support-quality question — expect a smaller, Symfony-6-only supported surface going forward. Budget for self-support if we depend on the removed paths.

Scaling No runtime or performance implications are evident in this release. The changes are dependency, test-tooling, and static-analysis oriented. Scale characteristics should be unchanged from v1.x.

Failure modes

• Fatal errors from removed EasyAdmin or SensioFrameworkExtraBundle integration classes at autoload or boot time — likely the first symptom on upgrade.
• Dependency resolution failure (composer update cannot satisfy Symfony 6 alongside pinned illuminate/* versions).
• Runtime failures on PHP 7.x environments if the platform constraint is only loosely enforced in CI.
• Silent divergence if we pin to v1.x and upstream stops patching it.

Ramp-up Low for engineers familiar with Symfony and Composer constraints; the package's own concepts are unchanged. The removed integrations slightly reduce documented surface area, which helps. The primary ramp-up cost is organizational, not technical: reconciling the Laravel-vs-Symfony framing and confirming which applications are actually affected.