Profiling Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is a Symfony bundle, not a Laravel package. It ships a Bundle subclass, a DI Extension, a Configuration tree, and event subscribers wired into Symfony's Kernel/Profiler lifecycle. Laravel has no bundle kernel, no profiler collector registry, and no config/packages/*.yaml merge model, so there is no drop-in install path into a Laravel codebase.
• What is genuinely portable is narrow: the pattern of serializing profiler payloads to human-readable artifacts (here, YAML) so they can be diffed in CI, archived, or attached to a ticket without access to the web profiler. That is a design idea plus a few hundred lines of serializer/dumper code, not an architecture.
• The reusable surface is roughly one class: a collector-to-file writer. Everything around it — bundle registration, collector tags, toolbar integration — is Symfony-specific and should be discarded rather than ported.

Integration feasibility

• Feasible only as inspiration, not dependency. A Laravel equivalent is an internal package that listens on RequestHandled/Terminate middleware and on Telescope's entry stream, normalizes payloads, and writes artifacts via symfony/yaml (already present transitively in most Laravel vendor trees) or symfony/serializer.
• For Laravel, the native substitutes are Telescope (storage plus watchers), Debugbar (request-scoped), and php artisan telescope:prune for retention. The first TPM question is whether Telescope plus a small telescope:export command already satisfies the "profiler data outside the web UI" need — most of the time it does.
• Reproducing the valuable behavior in Laravel: 1–2 engineer-weeks for a prototype covering request, query, and timing dumps, plus redaction and retention. Reading the Symfony source for patterns adds 2–3 days of overhead with limited payoff.

Technical risk

• Archived repository, 0 stars, 0 dependents. No maintainer, no issue triage, no security response. Adoption means a permanent internal fork commitment.
• Tight coupling to Symfony Profiler's internal data shape, which has moved across 5.x/6.x/7.x. A Laravel reimplementation avoids this, but the Symfony original would degrade silently on framework upgrades.
• Supply chain: adding an unmaintained, zero-audience package to composer.json creates a low-value but non-zero CVE and license-tracking obligation.
• YAML artifacts are verbose and slow at scale; full query logs and session snapshots blow up file size and routinely capture secrets.

Key questions

1. What is the real user need — CI regression diffing of query counts/timings, offline post-mortems, or audit retention? Each implies a different, smaller solution.
2. Does Telescope plus a telescope:export command cover ~80% of it?
3. Are we willing to own a fork indefinitely, or is this a one-time pattern extraction?
4. What is the data sensitivity of profiler payloads (auth tokens, session IDs, PII) and where would artifacts be stored or uploaded?
5. Is there any legacy Symfony service in the estate where the original bundle still adds value?

Integration Approach

Stack fit

• Target stack assumed: Laravel 10/11/12 on PHP 8.2+, with Symfony components available transitively.
• Do not add jinya/profiling-bundle to composer.json. Instead build an internal package (e.g. acme/laravel-profiler-export) providing:
  • a ProfileDumpServiceProvider;
  • a terminable middleware or RequestHandled listener;
  • collectors that adapt Telescope entries and DB::listen / Log events into a normalized array;
  • a writer behind an interface so YAML vs. JSON Lines is swappable.
• Keep the artifact schema ours, documented in-repo and versioned with a schema_version key. This is the single most valuable lesson from the Symfony bundle.

Migration path

• Phase 0 — Discovery (3–5 days): enumerate what engineers actually do with profiler data today; confirm Telescope coverage gaps and name the stakeholder who wants artifact capture.
• Phase 1 — Pattern extraction (1 week): read the bundle's dumper only, document the target artifact schema, choose the format (prefer NDJSON over YAML for diffing and size).
• Phase 2 — Prototype (1–2 weeks): request/query/timing collectors writing to storage/app/profiler/{env}/{date}/{request_id}.ndjson, gated behind an explicit env flag and a non-production guard.
• Phase 3 — CI wiring (1 week): artifact upload, a diff job against a baseline, threshold alerts on query-count or latency regressions.
• Phase 4 — Disposition: if a Symfony service exists, evaluate the bundle there in isolation; otherwise mark evaluated / not adopted in the dependency register with rationale.

Compatibility

• Pin symfony/yaml (or none at all if using JSON) explicitly rather than relying on transitive resolution, to avoid colliding with Laravel's own Symfony component constraints.
• Validate artifacts against a schema in CI (JSON Schema on converted output) so serializer drift is caught at build time, not during an incident.
• Add a contract test asserting schema keys, not values.

Sequencing

• Schema before writer, writer before collectors, collectors before CI diffing. Do not parallelize collectors and CI diffing — the artifact contract must stabilize first.
• Put a hard go/no-go gate after Phase 2: if Telescope export already meets the need, stop and bank the week.

Operational Impact

Maintenance

• Upstream maintenance is zero and permanent. Every bug, PHP upgrade, and format change becomes ours. Budget ~10–15% of one engineer for an internal replacement, or near-zero if Telescope export suffices.
• Forking the Symfony bundle is strictly worse than reimplementing: we would inherit Symfony-specific code we cannot use and still own the Laravel layer.

Support

• No upstream issues channel, no advisories, no release cadence. Ownership must be explicit: named maintainer, inclusion in the dependency inventory with an "unmaintained" flag, and a documented redaction policy.
• If used at all in a Symfony context, treat it as vendored code: copy into the repo, retain the MIT notice, do not rely on Packagist availability.

Scaling

• Artifacts grow linearly with request volume and payload size; even moderate traffic means gigabytes per day if unbounded. Requires sampling (1-in-N or error-only), per-file size caps, and a 7–14 day retention window.
• Serialization cost is material — dumping full query logs per request adds tens of milliseconds and measurable memory. Off by default, per-environment enablement, excluded from hot paths.
• Concurrency needs per-request filenames (ULID) and atomic write-temp-then-rename to avoid partial artifacts.

Failure modes

• Silent profiler breakage: internal API changes produce empty or malformed dumps, and CI diffs pass vacuously. Mitigate with a schema contract test plus a minimum-key-count assertion.
• Disk exhaustion: unbounded accumulation fills storage/. Mitigate with a retention job and a quota check before write.
• Secret leakage: profiler payloads routinely include session tokens, auth headers, and PII; artifacts uploaded as CI artifacts are an exfiltration vector. Mitigate with an allowlist of collected keys and mandatory redaction of Authorization, cookies, and request bodies.
• Production exposure: a misconfigured env flag enables dumping in prod. Mitigate with a compiled-in !app()->isProduction() guard, not a config toggle alone.
• Non-serializable objects: closures, resources, and lazy-loaded Eloquent models break naive serializers — normalize to scalars at collection time.
• Silent failure masking: a throwing dumper must be caught and logged at debug so it never breaks a request — but alert on dumper error rate so breakage is visible.

Ramp-up

• For a Laravel team: low to build the dumper, medium to design a stable schema and CI diffing engineers trust. Expect 2–3 weeks end-to-end including review.
• Documentation burden is real: schema reference, redaction policy, retention policy, and a "how to read an artifact" guide. Budget half an engineer-week.

TPM recommendation

• Do not adopt jinya/profiling-bundle. It is archived, has zero traction, targets the wrong framework, and its reusable surface is a single serializer pattern.
• Do leverage it as a design reference: extract the artifact-schema idea, validate the underlying need against Telescope first, and if a gap remains, fund a small internal build with a named owner and a documented schema contract.