Weave Code
Stack Trace Laravel Package
innmind/stack-trace
A lightweight PHP library for working with stack traces: capture them, inspect individual frames, and render readable traces for debugging and error reporting. Framework-agnostic and simple to drop into existing error handlers.
innmind/stack-trace renders PHP exception stack traces as clean, readable output. Instead of relying on the dense string produced by getTraceAsString(), it iterates over each frame and formats the call chain with consistent alignment, so errors are easier to scan in logs and CLI output.
- Aligned, easy-to-scan frame formatting
- Includes file, line, and call information per frame
- Supports chained/nested exceptions
- Simple integration into existing exception handlers
Frequently asked questions about Stack Trace
- Is innmind/stack-trace a Laravel package or framework-agnostic?
- It is framework-agnostic. The package models PHP stack traces as typed, immutable data and does not depend on Laravel's container, exception handler, or HTTP lifecycle. In a Laravel app it is an optional diagnostic primitive rather than a Laravel-specific integration.
- How do I install innmind/stack-trace in a Laravel application?
- Install it as a normal Composer dependency and confirm that its PHP constraint and innmind/immutable range resolve against your Laravel lockfile. The TPM assessment recommends checking with composer why-not before pinning, because the package is not part of Laravel's dependency graph. Do not retrofit existing error handling just to add it.
- Where should I use innmind/stack-trace in Laravel?
- The sanctioned call sites are narrow: a custom report() hook in bootstrap/app.php withExceptions(), a Monolog processor, or an internal error-aggregation job. Keep it out of controllers, middleware, and domain code. That preserves Laravel's normal exception rendering path while letting you inspect traces where reporting happens.
- Does innmind/stack-trace replace Laravel's exception handler or error renderer?
- No. It is a parsing and inspection primitive for stack traces, not an error-handler replacement. In Laravel it should sit behind the existing exception pipeline, for example in report() or a logging processor, rather than in place of Laravel's handler or a rendering package.
- Can innmind/stack-trace find the first application frame in a vendor-heavy stack trace?
- That is one of the realistic use cases described in the assessment: stripping or filtering vendor frames to locate the first application frame. The package is intended to give structured access to frames instead of raw array traversal. Verify the exact origin-frame API and edge-case behavior before relying on it.
- Does innmind/stack-trace traverse chained exceptions with getPrevious()?
- The assessment flags this as a key question for the maintainer or a spike, not a confirmed feature in the excerpt. Chained exceptions are a common source of incomplete traces, so confirm whether the package walks getPrevious() and exposes those frames. If it does not, you will need to handle chaining in your adapter.
- How does innmind/stack-trace handle zend.exception_ignore_args and sensitive frame arguments?
- The assessment calls out zend.exception_ignore_args and truncated string parameters as edge cases to test. The package may expose frame arguments, which makes redaction important before logging. Confirm its behavior under your PHP ini settings and keep sensitive-argument stripping in your own reporting layer.
- Can I use innmind/stack-trace to fingerprint or group exceptions?
- Yes, stack-trace fingerprinting for error deduplication and grouping is listed as a realistic Laravel use case. The idea is to derive a stable fingerprint from structured frames rather than from a formatted trace string. Validate fingerprint stability across PHP versions and frame-shape edge cases.
- What compatibility and maintenance risks should I check before using innmind/stack-trace?
- Check the exact composer.json constraints for PHP, innmind/immutable, and any PSR conflicts against Laravel 10, 11, or 12 on PHP 8.1+. The assessment also notes low adoption, a single maintainer, and a future-dated release entry, so verify tags, changelog discipline, and a green test suite before pinning. Treat it as supply-chain risk, not just a functional decision.
- Should I wrap innmind/stack-trace behind an adapter in a Laravel app?
- Yes, an anti-corruption layer is the recommended integration approach. Define your own TraceInspector interface and DTOs such as TraceFrame, OriginFrame, and Fingerprint, then implement them with an InnmindTraceInspector adapter. That keeps innmind/immutable types out of application code and makes replacement a one-class swap if the package is abandoned or proves brittle.
Weaver
How can I help you explore Laravel packages today?