- What is thejenos/laradump and what does it do?
- thejenos/laradump is a Laravel debugging package that provides cleaner, more readable dumps for inspecting variables and application state during development. It is positioned as a free alternative to Spatie Ray, so the intent is to ship dump-style payloads to an inspector rather than dumping into the HTTP response body. It is a narrow, dev-tooling utility with no application-layer role, and it belongs alongside tools like Telescope, Clockwork, and Laravel Debugbar in the local debugging slot. It is not a replacement for those tools; it overlaps with them.
- Is thejenos/laradump still maintained?
- No. The repository is archived, it has a single maintainer with no obligation to respond, and the last release was on 2021-11-22. There is no vendor, no support contract, and no CVE or security response path. With roughly 21 stars and zero dependents, nobody has validated it against modern Laravel, Octane, or PHP 8.2 and above. Treat your own team as the de facto auditor if you evaluate it.
- Does laradump work with Laravel 10 or Laravel 11?
- There is no official support for Laravel 10 or 11. A package last released in November 2021 will typically constrain illuminate/support to Laravel 8 or 9 and PHP 7.4 to 8.0, so Composer will refuse to resolve on Laravel 10/11 with PHP 8.1 and above. Forcing installation with --ignore-platform-reqs pushes unverified code into your autoloader and is not recommended. At minimum you would need to fork the package and patch its composer.json constraints yourself.
- How do I install thejenos/laradump in a Laravel project?
- Mechanically it is trivial: composer require --dev thejenos/laradump, publish the config if one is offered, and call the package's helper where you want a dump. A single engineer can complete an evaluation in under a day. The blocker is version compatibility, not installation effort, so confirm the PHP and illuminate/* constraints before you start. Install it in require-dev only and never in require.
- Is laradump a good free alternative to Spatie Ray?
- Only in the narrow sense that it targets the same dump-to-inspector workflow without a license fee. It is an archived, single-maintainer package whose last release predates Laravel 10, so the maintenance and compatibility gap versus Ray is significant. For teams already standardized on Ray, Telescope, or Xdebug plus a dump server, the marginal capability is near zero. A time-boxed spike is defensible, but a team-wide or production commitment is not.
- What are better-maintained alternatives to laradump for Laravel debugging?
- The honest comparison set is Clockwork, Laravel Telescope, Laravel Debugbar, and Xdebug step debugging. Telescope is first-party and covers request, job, and query introspection, while Clockwork and Debugbar are mature and actively maintained. Xdebug sends no payload off the machine at all, which is the safest exposure profile. Pick from that set first and document why laradump was rejected.
- Should laradump be installed as a dev dependency only?
- Yes. It is a dev-tooling concern, not an application dependency, so it should live in require-dev with auto-discovery and no production configuration. Any usage outside local or staging is a design defect. Keep it out of your deployable artifact's production autoload path entirely, and do not normalize it in a fleet-wide developer workflow.
- Does laradump work with Laravel Octane, queue workers, and Docker?
- This is unverified. Dump-channel packages frequently assume a per-request lifecycle, and behavior under Octane, queue workers, and php artisan serve inside containers has not been tested by the ecosystem. In Docker, localhost in the container is not the host machine, which commonly breaks HTTP-based dump transports. Confirm the transport and lifecycle assumptions yourself before relying on it in long-lived workers.
- Is laradump safe to use in production or shared staging environments?
- No. Dump tools that render payloads over HTTP or persist them can leak environment values, API tokens, or PII if the endpoint is reachable beyond localhost. Shared staging and Docker networks bound to 0.0.0.0 are the highest-risk cases. You should also verify whether the package registers any route and whether that route is gated to local and APP_DEBUG before exposing it anywhere.
- What should I check before adopting laradump in a team workflow?
- Resolve five things first: what the transport is (HTTP listener, database-backed viewer, log file, or browser console), whether it registers a route and how that route is gated, the exact composer.json constraints for PHP and illuminate/*, whether a companion viewer client exists and is maintained, and whether it works under Octane, queues, and Docker. A dumper without a maintained viewer is inert. Given the archived repo and zero dependents, also decide up front who on your team reviews the source.