Psysh Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for interactive debugging tooling — this is a 5-star, 0-dependent Symfony port of PsySH. For a Laravel shop it supports exactly one decision: don't adopt. There is no capability gap it fills.
• Feature/roadmap scoping — the underlying question it answers ("do we give engineers a REPL wired into the framework container?") is already answered in Laravel by php artisan tinker, which has shipped first-party for years with Eloquent, container, config, and queue context pre-loaded.
• Use cases it would nominally serve — poking at container services, inspecting the event dispatcher, ad-hoc entity/repository queries in dev and staging shells. All of these are covered by existing tooling in our stack.
• Dependency governance — it's a useful data point for a "minimum adoption bar" policy: 5 stars, 0 dependents, single-maintainer wrapper around someone else's library. Good candidate for the reject list, not the roadmap.

When to Consider This Package

Adoption criteria:

• You run Symfony, not Laravel, and want a REPL without hand-writing a console command.
• You've confirmed compatibility with your Symfony and PHP versions — it's a port, so it structurally trails upstream PsySH releases.
• You accept single-maintainer risk and have no vendor-support requirement.

Look elsewhere when:

• You're on Laravel. Use php artisan tinker (zero extra dependency, first-party) or require psy/psysh directly for standalone/scripted use.
• You want the maintained artifact. composer require --dev psy/psysh plus a ~20-line console command reproduces this bundle's value against the upstream project rather than a wrapper.
• You need community vetting. Zero dependents means no de facto production validation and no downstream bug surface to learn from.
• You need production-safe introspection. REPLs are dev-only tooling regardless of which path you pick; plan the environment gating either way.

One caveat to verify before citing project health anywhere: the "last release" timestamp (2026-10-05) is in the future relative to normal release cadence, which reads as anomalous registry metadata rather than evidence of active maintenance. Treat it as unverified.

How to Pitch It (Stakeholders)

Executives: Not a fit for our stack. This is a thin Symfony port of an existing open-source REPL — MIT licensed, so no cost, but negligible adoption (5 stars, 0 dependents) and single-maintainer risk. Laravel already ships equivalent functionality in artisan tinker, so adopting it would add a dependency without adding capability. Recommendation: no action.

Engineering: The value prop is "REPL inside the framework container without writing a command." We're not on Symfony, and even there I'd default to requiring psy/psysh directly and writing the small integration ourselves — upstream PsySH is the maintained artifact; this bundle trails it by construction. For Laravel, artisan tinker is the sanctioned path; for standalone or scripted use, add psy/psysh as a dev dependency. If someone wants a case study in why we set a dependency adoption bar, this is a clean example: right idea, wrong ecosystem, no maintenance signal.