Perf Collector Bundle Laravel Package

Product Decisions This Supports

• Framework-upgrade unblocking. RC1's Symfony constraint made the package uninstallable on Symfony 8 — i.e. on the applications it targets. RC2 removes a hard blocker on any Laravel/Symfony 8 upgrade path that includes this dependency. This is a go/no-go input for the upgrade plan, not a feature decision.
• Build vs. buy for performance instrumentation. Whether to adopt a third-party collector or keep investing in in-house instrumentation and Laravel-native tooling (Telescope, Pulse, Debugbar). Requires an explicit overlap/gap analysis before commitment — the release notes do not describe feature scope.
• Supply-chain and dependency policy. Moving from a VCS repository block to Packagist listing means the package can flow through standard vendor review, lockfile pinning, and vulnerability scanning instead of a per-project repository exception.
• Pilot scoping for CI performance budgets. A low-cost, timeboxed pilot (query counts / timing thresholds in CI) is now technically feasible on Symfony 8 without patching Composer config.

When to Consider This Package

Consider it when:

• You are on, or planning, Symfony 8 components (including via a Laravel upgrade) and need a Composer-installable perf collector without custom repositories entries.
• You want instrumentation available in CI and container builds where Git credentials for a VCS repository are undesirable or unavailable.
• You can accept a pre-stable stability contract: pin the exact RC version, isolate usage behind an internal interface, and treat the API as subject to change.

Look elsewhere when:

• You need a stable-version guarantee or vendor LTS/security-review sign-off for a long-lived production surface.
• Existing Laravel tooling already answers your performance questions — validate the gap before adding a dependency.
• Your policy forbids release candidates in the production dependency tree; in that case treat RC2 as evaluation-only and wait for stable.

Adoption caveat for engineering: RC1's failure was Composer constraint hygiene, not runtime behavior (no code change was needed for Symfony 8.1). Add a composer require smoke test across your supported framework matrix to future releases rather than relying on the package's own CI alone.

How to Pitch It (Stakeholders)

Executives: A small, low-commitment dependency that is now installable on our target stack and no longer blocks the framework upgrade. It is still a release candidate, so the recommendation is a timeboxed pilot — not a platform commitment.

Engineering: Install from Packagist with no VCS repository block; the existing suite passes on Symfony 8.1 and CI now covers it. Pin the exact RC version, confirm it does not duplicate existing observability, and track the stable release. Note the RC1 constraint regression as a signal to validate future upgrades with our own install test rather than trusting upstream CI.