Mysqlnd Bundle Laravel Package

Technical Evaluation

Architecture fit — still poor, and the mismatch remains categorical. js/mysqlnd-bundle is a Symfony2 bundle, not a Laravel package. Bundles are discovered and booted by Symfony's Kernel, register services through DependencyInjection\Extension, and render toolbar panels through Twig resources registered with WebProfilerBundle. Laravel has no code path that will ever load any of that. There is no ServiceProvider, no register()/boot(), no route or view namespace handshake, and Laravel's profiler equivalent (Debugbar, Telescope, Clockwork) has its own collector contract unrelated to Symfony's DataCollectorInterface.

v1.1.2 does not move this needle — it reinforces it. The change (app.request instead of request in the Twig template, fixes #7) is a Symfony 2 templating-scope correction inside Resources/views/. It is a fix to precisely the layer we recommend deleting, and it is written against the Twig global-variable conventions of that era. The patch touches zero PHP classes, adds no Laravel integration surface, and leaves the DI wiring, the DataCollectorInterface implementation, and the Symfony version constraints untouched.

The genuinely valuable asset here remains narrower than the package: the logic that reads mysqlnd's per-connection and per-client statistics (mysqli_get_connection_stats(), mysqli_get_client_stats()) and shapes them into query timings, bytes sent/received, and connection health. That logic is a few hundred lines and is driver-level, not framework-level. Everything around it — DI wiring, Twig toolbar template, Symfony version constraints — is dead weight for our stack.

Integration feasibility — still fork-and-extract, not a dependency. composer require johannes/mysqlnd-bundle will fail resolution on any modern Laravel app: the package declares constraints against Symfony 2.x full-stack components, while Laravel 10/11 pulls individual Symfony components at ^6/^7. There is no overlap, and v1.1.2 does not touch composer.json. Even with --ignore-platform-reqs, the bundle's extension classes reference Symfony 2 APIs (DataCollectorInterface::getName() signature, TimelineDataCollector, TemplateManager) that no longer exist in that form.

Realistic effort for a mid-level PHP engineer: 1–2 weeks, split roughly 20% reading/stripping the bundle, 50% porting the stats-collection logic into a host collector, 30% validation against our actual MySQL workload. Low line count, moderate archaeology. Unchanged by this release.

Technical risk — high, still dominated by abandonment, with one nuance. The core is a PHP 5.3/5.4-era codebase. Expect the usual PHP 8 breakage surface: no scalar/return types, dynamic property creation, removed functions, curly-brace string offsets, old-style constructors. The opportunity: 0.76 score remains the honest read — the capability gap is real (Laravel gives you DB::listen() SQL timings but nothing at the driver/wire level), while the artifact is stale. Treat this repository as prior art and reference implementation, not as a dependency.

The one thing v1.1.2 changes is the "is anyone home?" signal. A tagged patch means upstream is not formally archived and someone can still merge. That is not good news for us: the activity is confined to cosmetic Symfony 2 template fixes, which is enough to keep the project nominally alive but not enough to produce PHP 8 compatibility, dependency bumps, or a Laravel path. Partial liveness is arguably worse than dormancy, because it creates a plausible-looking reason to wait for upstream instead of forking. Ownership still lands on us either way.

Second risk layer, unchanged: mysqlnd itself. The package assumes the mysqlnd driver is present. If production or staging PHP was compiled pdo_mysql/mysqli against libmysqlclient (common on older distro packages), the stats functions simply do not exist and the collector fails rather than degrading.

Key questions to resolve before any commitment:

Integration Approach

Stack fit. Assume Laravel 10/11, PHP 8.2+, MySQL 8.x, pdo_mysql on mysqlnd. Under those assumptions the extraction target is barryvdh/laravel-debugbar: a custom DataCollector extending DebugBar\DataCollector\DataCollector, registered via DebugBar::addCollector() in a service provider, gated on config('debugbar.enabled'). That gives us the toolbar panel, and the Twig template problem evaporates — Debugbar renders from PHP arrays, not Twig. Notably, v1.1.2's app.request fix is inside the exact file we delete, which is a clean illustration of how little of this package survives the port. If the goal is production-grade telemetry instead, the target is a Telescope Watcher, but Telescope's storage model is a poor fit for high-cardinality per-query driver stats and I would not lead with it.

Migration path — three options, ranked:

1. Fork and port to a Debugbar collector (recommended). Vendor the source under our namespace, rewrite composer.json to require only php, ext-mysqli/ext-pdo, and Laravel/Debugbar. Strip DependencyInjection/, JSMysqlndBundle.php, Resources/ (including the template v1.1.2 patches). Keep and modernize the stats aggregation and the display shaping. BSD-3-Clause permits this with attribution retained. This preserves the one thing worth preserving and discards the framework coupling that has zero value here.
2. Reimplement independent of the repository. If the port surfaces more PHP 5 legacy than expected, write the collector from scratch against mysqli_get_client_stats(). It is a small enough surface that reading the old code as documentation and writing fresh may be cheaper than modernizing it.
3. Abandon and compose. Telescope + DB::listen() + periodic performance_schema snapshots. Zero maintenance burden, but does not give per-connection wire-level detail.

Compatibility constraints to encode: PHP 8.2+ only, Laravel 10/11 only, ext-mysqli required, explicit runtime guard that checks extension_loaded('mysqlnd') and silently disables the collector otherwise. Do not attempt to keep Symfony or Twig compatibility — v1.1.2 is evidence that upstream will keep investing in that layer, and mirroring it doubles our test matrix for zero consumers.

Sequencing:

• Phase 0 (1–2 days): Verify mysqlnd across local/staging/prod. Establish the baseline of what DB::listen() and Telescope already report for our top-10 slowest endpoints. If the delta is small, stop here.
• Phase 1 (3–5 days): Fork, strip, and port the stats aggregation into a Debugbar collector registered behind a config flag. Ship to local dev only.
• Phase 2 (3–5 days): Validate against representative workloads — N+1 patterns, long transactions, connection churn under queue workers. Confirm byte counts and timings reconcile with SHOW SESSION STATUS.
• Phase 3: Document, add to the internal dev-tooling registry, assign an owner, and set a review date. Never enable outside APP_DEBUG=true.

Operational Impact

Maintenance. Assume 100% internal ownership from day one. v1.1.2 does not change this: a Twig variable-scope patch is not a maintenance commitment, and there is still no evidence of PHP 8 work, dependency bumps, or a release cadence we can plan around. Budget a few days per year for PHP/Laravel upgrade churn. Mitigate by keeping the fork small and dependency-free — the smaller the surface, the cheaper the annual tax. Pin the fork internally rather than publishing it; nothing about this code is worth open-sourcing back.

Support. No vendor, no maintainer commitment, no CVE feed. BSD-3-Clause means we can modify freely but inherits no warranty. The real support question is whether the tool is load-bearing: if engineers come to depend on driver-level query stats, removing it during an incident becomes a negotiation. Document it explicitly as a dev-only diagnostic, not a production observability dependency, so no runbook ever cites it.

Scaling. Correctly scoped, scaling impact is zero: the collector runs only in local/dev, where one request per process is the norm. The risk is scope creep into staging or production. mysqlnd statistics are cumulative per-connection and per-process; under php-fpm with high concurrency, enabling collection adds per-query bookkeeping and unbounded in-memory aggregation that will grow with request volume. Set an explicit hard gate — environment check and an explicit config opt-in — rather than relying on APP_DEBUG alone, since APP_DEBUG is frequently misconfigured in staging.

Failure modes:

Ramp-up. Reading the codebase is a half-day for any PHP developer — it is small and the mysqlnd API surface is narrow and well-documented. The friction is institutional, not technical: someone must own an orphaned fork, and the team must internalize that mysqlnd reports driver-level facts (bytes on the wire, connection reuse, wait time) that DB::listen() deliberately does not. That distinction is the entire value proposition, and it is also the reason a hasty port will disappoint — if the team expects query plans or index advice, they will find neither here.

Recommendation. Unchanged after v1.1.2. Do not adopt this package as a dependency; the Symfony2/Twig packaging makes that a non-starter, and a cosmetic template fix does not signal a revival. Do treat it as a reference implementation for a small, internally-owned Debugbar collector, contingent on Phase 0 confirming that mysqlnd is actually the driver and that the driver-level data answers a question our existing tooling cannot. If Phase 0 comes back negative, close this out and stay on Telescope.