Runtracy Laravel Package

Technical Evaluation

Architecture fit

The first thing a TPM has to flag is a framing mismatch: runcmf/runtracy is not a Laravel package. It is a thin glue layer that wires the Tracy debugger (Nette's mature error-handler/dump/Debugger-Bar library) into Slim Framework. There is no service provider, no facade, no config-publishable file, no Blade/Telescope/Ignition integration, and no laravel/framework dependency in the manifest. The package's only job is: bootstrap Tracy, register the Bar panel, and hook Slim's error handler so exceptions render through Tracy instead of Slim's default renderer.

Consequently, fit splits sharply by context:

• Laravel-first estate: poor fit. Laravel already ships Ignition (or Whoops on older versions) plus Telescope and Debugbar. Adopting runtracy buys nothing that the native stack doesn't already do, and it introduces a competing global error/exception handler — a genuine source of conflict with Laravel's Handler pipeline.
• Slim microservices estate: reasonable fit for Slim 3-era services. It is a ~100-line convenience wrapper over a library you would otherwise wire by hand, so the value is convenience, not capability.
• Mixed estate: the realistic use case is a platform team with a handful of legacy Slim services adjacent to a Laravel monolith. That narrows the addressable audience considerably and explains the 0 dependents.

Integration feasibility

Composer-installable and PSR-4 autoloaded, so mechanical integration is trivial where it targets the right framework. Feasibility is gated by three things a TPM should verify before committing engineering time:

1. Slim major version. Last release 2017-05-24 places this squarely in the Slim 3 window. Slim 4 moved to PSR-15 middleware and a different container/error-handler contract, so the glue almost certainly does not work unmodified. Treat "works with Slim 4" as unproven until spiked.
2. PHP platform constraints. A 2017-era tracy/tracy 2.x pin will collide with PHP 8.x via composer require platform checks, and Tracy 2.x itself had deprecation-level breakage on 8.1+. Any modern runtime requires a fork-and-patch, not an install.
3. Dev-only enforcement. A debugger that renders stack traces, env vars, request payloads, and SQL is a production information-disclosure vector. The package provides no environment gate of its own; that discipline must be enforced by the consuming app.

Technical risk

• Abandonment risk: high. Seven-plus years without a release, single-maintainer profile, 0 dependents. This is effectively a vendored snippet, not a maintained dependency.
• Upstream-is-fine risk: low. Tracy itself remains actively maintained. The correct mitigation is therefore cheap: drop the wrapper and call Tracy directly from a small piece of Slim bootstrap code. That reframes the whole decision — you are not evaluating a library, you are evaluating whether to keep ~100 lines of 2017 glue alive.
• Upgrade-path risk: high. This dependency is a plausible blocker on any Slim 3 → 4 migration or PHP 8 upgrade, both of which land on the roadmap eventually.
• Supply-chain risk: moderate. Apache-2.0 with patent grant, so forking is legally clean; but no security response process, no CVE feed, and SCA tooling will flag it as stale on every scan.

Key questions

1. Which Slim major version do our affected services actually run, and is a Slim 4 migration already scheduled?
2. Is there a hard requirement to expose debug output to Laravel apps, or is that a misread of the package name in our intake?
3. What is our policy on forking single-maintainer dev dependencies — do we have an internal package registry with a named steward?
4. Can we enforce dev-only loading at the platform level (e.g., require-dev plus a APP_DEBUG guard), or does that rely on each team's discipline?
5. What does our SCA baseline say about tracy/tracy 2.x transitively?

Integration Approach

Stack fit

Segment by runtime, not by package name. For Laravel services, the answer is no — map the underlying need to Ignition + Telescope + a Debugbar panel, which are maintained, first-party-adjacent, and already understood by the team. For Slim 3 services, the answer is yes, conditionally, and preferably by reproducing the glue internally rather than consuming the abandoned package. For Slim 4 services, the answer is not without a rewrite, at which point writing native PSR-15 middleware is the same effort with a better ownership story.

Migration path

Two viable paths, both cheap:

• Path A — private fork. Vendor runcmf/runtracy into an internal package, bump the tracy/tracy constraint to a maintained 2.x/3.x line, patch PHP 8 incompatibilities (dynamic properties, removed functions), add a APP_DEBUG-style hard gate, and publish to the internal registry. Estimate 1–3 engineer-days including a PHP version matrix in CI.
• Path B — replace with native glue (recommended). Delete the dependency. In Slim bootstrap, enable Tracy behind an environment flag and register the Bar; keep Tracy pinned and upgradeable independently of the wrapper. Estimate ~1 engineer-day, and it eliminates the abandoned-dependency finding entirely.

Path B is the better default because it converts a stale third-party artifact into ~30 lines the team owns and can read in one sitting. Path A is justified only if multiple teams need identical behavior and a shared internal package reduces duplication.

Compatibility

Assume Slim 3-only until proven otherwise; assume PHP 7.x-era constraints. Expect Composer conflict friction against any framework or tooling that requires modern tracy/tracy, and expect the fork to be the moment you discover what else in the tree pins Tracy. On the Laravel side there is no compatibility story at all — no package discovery, no config merge, no handler integration — so any attempt to force it in is bespoke adapter work with no upstream support.

Sequencing

1. Inventory — which repositories reference Slim at all, and at which major version. This is likely a short list and should be done first; it may make the decision for you.
2. Spike in one non-production Slim 3 service — confirm it boots, the Bar renders, and exceptions route correctly under the target PHP version.
3. Decide Path A vs. Path B based on the inventory breadth (one service → Path B; five services → Path A).
4. Harden — environment gate, require-dev only, CI job asserting the debugger is inert when the flag is off.
5. Publish and document — internal registry entry, README with the gate contract, and an explicit note that upstream is unmaintained.
6. Backlog the exit — tie the package's retirement to the Slim 4 migration so it does not silently persist for another five years.

Operational Impact

Maintenance

Upstream is dormant, so maintenance cost transfers entirely to us. Budget a named steward and roughly 2–5% of an FTE annually for a fork (dependency bumps, PHP matrix, security triage), or near-zero for Path B since the surface is small and Tracy is upgraded independently. Apache-2.0 makes the fork legally uncomplicated, which is the main thing this package has going for it.

Support

No vendor, no SLA, no release cadence. Community Q&A only. In practice the support burden lands on Tracy's documentation, which is good and actively maintained — another argument that the wrapper adds little. An internal runbook is mandatory: how to enable, how to disable, what the gate variable is, and who to page if the debugger misbehaves in a shared environment.

Scaling

This is a development tool, so production scaling impact should be zero — if the gate holds. Tracy's Bar adds per-request instrumentation, panel rendering, and dump buffering; under high request rates with the gate accidentally open, expect measurable latency and memory growth plus unbounded log/dump capture. The real "scaling" concern is organizational: the more services adopt it, the more places a misconfigured environment variable can leak internals.

Failure modes

• Debugger live in production — highest-severity failure; exposes stack traces, environment variables, request bodies, session data, and query text. Mitigate with a hard gate that fails closed and a CI assertion.
• PHP runtime incompatibility — fatal errors at bootstrap on 8.x, which is a total service outage rather than a degraded debug experience.
• Composer resolution conflict — the package blocks a framework or security upgrade, discovered at the worst possible moment during an upgrade sprint.
• Slim 4 migration blocker — a dormant dev dependency becomes a line item on an architecture migration.
• Panel exception swallowing the response — Tracy degrades gracefully in most cases, but a misbehaving panel can produce a blank response on error paths, which is confusing to diagnose precisely when you most need the error output.
• SCA noise — every dependency scan flags it, generating recurring triage toil for the security team.

Ramp-up

Low for PHP engineers already familiar with Tracy or Symfony VarDumper/Debugbar — roughly half a day to read the glue and understand the gate. Higher for Laravel-only engineers, who will reasonably ask why they aren't using Ignition, and whose instinct is correct. The ramp-up cost is not learning the tool; it is learning why this tool exists here, which is an architectural question the TPM should answer in writing before adoption.