Ez Legacy Debug Bundle Laravel Package

Technical Evaluation

Architecture fit — fundamental mismatch. The intake record is labeled a "Laravel/PHP package," but mmz-srf/ez-legacy-debug-bundle is a Symfony bundle, not a Composer library with framework-agnostic surfaces. It exists solely to surface eZ Publish Legacy (eZLegacy) debug information inside Symfony's WebProfilerBundle via a custom data collector and Twig panel. It has no service provider, no Laravel-facing config, no facades, and no contracts that could be bound into a Laravel container. For a Laravel roadmap this is a non-candidate; for a Symfony/eZ Publish Legacy roadmap it is a dev-tooling convenience from the Symfony 2 era.

Integration feasibility — effectively zero as-is. A Symfony bundle registers through AppKernel/bundle manifests and depends on the Symfony 2 Profiler collector API (DataCollectorInterface with getName/collect/getMenu/getPanel), WebProfilerBundle templating conventions, and the eZ Publish Legacy bridge (ezsystems/ezpublish-legacy / legacy kernel). Modern Symfony (Flex, Symfony 5+) removed or reworked the relevant collector and templating contracts; Laravel has no equivalent surface at all. Any integration would be a rewrite of the collector plus a new adapter for whatever debug source we actually have — not a package adoption.

Technical risk — high, but contained by scope. Last release 2015-09-16, archived, 2 stars, 0 dependents, score 0.005. That combination means: no security response, no PHP 7/8 compatibility, no dependency hygiene (Symfony 2 reached EOL in Nov 2018; the PHP 5.x line it targeted is long EOL). The tool is debug-only, which limits blast radius, but it hooks the request lifecycle and renders internal diagnostics (SQL, template resolution, legacy kernel state). The realistic risk is not a production exploit path but accidental enablement in a non-dev environment and data exposure of internal paths/queries in a profiler panel.

Key questions for intake:

• Is this record mis-catalogued? The Laravel framing conflicts with the artifact — correct the catalog metadata before it pollutes package scoring or a "Laravel packages" shortlist.
• Do we actually operate eZ Publish Legacy anywhere? If not, close this immediately with no further review.
• If yes: what is the current Symfony version in that estate, and is WebProfilerBundle still in use?
• What problem is being solved — legacy debug visibility, or profiler coverage in general? A modern VarDumper/Monolog/debug channel likely covers the need without a 2015 bundle.
• Is this being evaluated as a replace/retire item (i.e., flagged as technical debt) rather than an adoption candidate?

Integration Approach

Stack fit. Zero fit for Laravel — there is no migration path that preserves this package's code. A Laravel-side equivalent would be a Telescope watcher or a custom Debugbar collector, written from scratch. For Symfony, fit is limited to Symfony 2.3–2.8-style applications that also run eZ Publish Legacy; anything on Symfony 4+ requires a fork with a rewritten collector.

Migration path. Recommended path is rejection at intake, documented as "archived, framework-mismatched, single-purpose dev tool." No POC warranted. If a specific team insists there is a live need, the only viable path is: (1) confirm the eZ Legacy + Symfony 2 estate still exists, (2) fork into an internal namespace, (3) port the collector to the Symfony version in use, (4) add a hard dev-only environment guard. That is a 1–2 sprint piece of work to reproduce a debugging convenience — a poor trade unless the legacy estate is large and long-lived.

Compatibility. Assumes PHP ~5.5/5.6, Symfony 2.x, WebProfilerBundle, and the eZ Publish Legacy bridge. Incompatible with PHP 8.x, Symfony 5/6/7, and any Laravel version. Composer resolution against a current lockfile will fail or force unacceptable downgrades — treat it as a pinning hazard if anyone tries composer require speculatively.

Sequencing. (1) Correct the catalog entry and mark as rejected/non-Laravel. (2) If an eZ Legacy estate exists, run a separate discovery on its debug/observability stack and evaluate modern replacements there. (3) Only if discovery confirms a hard requirement, scope a fork under an internal owner. Do not sequence this ahead of any active Laravel initiative.

Operational Impact

Maintenance. Zero upstream maintenance — archived since 2015. Any adoption transfers full maintenance liability in-house with no upstream to rebase against. Dependency upgrades (PHP, Symfony) would be entirely on us.

Support. No vendor, no community (2 stars, 0 dependents), no issue triage. Knowledge is effectively concentrated in the original author. Internal support would require a named owner with Symfony Profiler and eZ Legacy expertise — a scarce combination.

Scaling. As a dev-only profiler extension, it does not affect production scaling directly. However, eZ Legacy debug collection is typically heavy (query logging, template/variable dumps); enabling it against large content sets can materially slow local/staging requests and inflate memory. The panel is per-request, so there is no horizontal scaling story to evaluate — it is an on/off risk, not a load risk.

Failure modes.

• Bundle registration or collector API mismatch on any modern Symfony → boot failure or silently missing profiler panel.
• PHP fatal errors from removed/deprecated language and framework APIs on PHP 7.4+.
• Blank or partial panel when eZ Legacy debug handlers are not wired, producing misleading "no data" signals during debugging.
• Environment leakage: if enabled outside dev, exposes internal paths, queries, and legacy kernel state to anyone with profiler access.
• Composer resolution failures or forced downgrades that destabilize an unrelated application.

Ramp-up. Onboarding cost is disproportionately high for the value: a TPM would need to justify an engineer learning a 2015 Symfony 2 profiler integration and the eZ Legacy debug pipeline to maintain a panel that modern tooling largely supersedes. Estimated ramp-up is days-to-weeks for a tool whose entire function is convenience-grade diagnostics.

TPM recommendation: reject. The artifact is framework-mismatched (Symfony bundle vs. Laravel), archived, unmaintained, and has no adoption signal. Correct the intake record's categorization, close the evaluation, and if legacy debug visibility is a genuine requirement, fund a small modern observability solution on the actual stack instead.