Psysh Bundle Laravel Package

Technical Evaluation

Architecture fit. teamdotblue/psysh-bundle is a Symfony bundle, not a Laravel package. It registers a psysh console command inside a Symfony kernel and wires PsySH to the Symfony DI container so developers can introspect services, parameters, and the kernel from a REPL. Our target stack is Laravel, which does not use bundles, the Symfony kernel, or bundle registration — so the package's core value proposition (container-aware introspection via a kernel) has no place to attach. The functionally equivalent capability in Laravel is already first-party: laravel/tinker wraps the same upstream PsySH engine and exposes the Laravel container, Eloquent models, and app bindings out of the box. From an architecture standpoint this package is a duplicate of a capability we already own, delivered through an integration layer we cannot consume.

Integration feasibility. Technically installable via Composer, but only useful inside a Symfony application. Forcing it into a Laravel app would mean pulling in symfony/framework-bundle and standing up bundle bootstrapping purely to reach a REPL we already have — negative value. Realistic integration options are limited to (a) Symfony services that remain in a polyglot estate, where the bundle can be used natively, or (b) ignoring the bundle and using upstream psy/psysh directly with a hand-rolled bootstrap. Neither path advances our Laravel roadmap.

Technical risk.

• Stack mismatch (high): the package is purpose-built for Symfony's kernel/DI model; no supported path into Laravel.
• Viability (high): 5 stars, 0 dependents, and a single-maintainer footprint indicate a hobby-scale project with a bus factor of one. Dependency-constrained Symfony/PHP versions are likely to lag current Symfony 6/7 and PHP 8.2+ baselines.
• Security surface (high, inherent): a REPL is remote code execution by design. Any adoption requires it be a require-dev dependency, excluded from production autoload, and gated behind environment checks. This is a known, manageable risk — but it is risk we take on for zero incremental capability.
• Licensing/compliance (low): MIT, no copyleft concerns.
• Score signal: the composite score of ~19.5 with opportunity at ~41.6 corroborates the qualitative read — commoditized functionality, thin adoption, weak maintenance signal.

Key questions.

1. Do we operate any Symfony services where a container-aware REPL is genuinely missing, or is this purely a Laravel evaluation?
2. What developer problem are we solving that php artisan tinker does not already solve?
3. If a team is using this bundle today, what custom casters or config have they built on top of it, and how portable are they?
4. Who owns the security guardrail ensuring REPL tooling never reaches production?

Integration Approach

Stack fit. Poor for Laravel, adequate for Symfony. The correct Laravel answer is laravel/tinker (first-party, actively maintained, same PsySH engine, container- and Eloquent-aware). Recommendation: do not adopt for Laravel services; treat psysh-bundle as out of scope unless a Symfony service is explicitly in scope.

Migration path. For any legacy Symfony service currently using the bundle, the exit path is composer remove teamdotblue/psysh-bundle plus a psy/psysh dev dependency if standalone REPL access is still wanted. For teams moving from Symfony to Laravel, map the mental model: $container->get('service') becomes app('service'); kernel/service introspection becomes facades, app(), and Eloquent; custom casters are largely unnecessary because Tinker handles models natively. Budget roughly 0.5–1 engineer-day per service for the swap and documentation, plus a short pairing session to retrain habits.

Compatibility. Verify PHP and Symfony constraint ranges before any short-term retention decision; a package that cannot resolve against our PHP 8.2+ baseline is a forced migration regardless of preference. On the Laravel side, confirm laravel/tinker version alignment with the framework version in each service — this is a routine, well-trodden constraint.

Sequencing.

1. Inventory (week 1): grep the estate for psysh-bundle and psy/psysh in composer.json files; classify each hit as Laravel or Symfony.
2. Decide per class: Laravel hits convert to laravel/tinker; Symfony hits get a pin-and-audit or a standalone-PsySH replacement.
3. Pilot (week 2): convert one low-risk service, validate developer ergonomics, capture any lost functionality.
4. Standardize: publish a one-page "REPL tooling" standard naming laravel/tinker as the sanctioned option and documenting the dev-only guardrail.
5. Roll out and decommission the bundle across remaining services, with a CI check that flags the package in any composer.json.

Operational Impact

Maintenance. Community-only, no vendor SLA, one maintainer. Consuming it means we own the upgrade path ourselves — patching version constraints, absorbing PHP deprecations, and watching an issue tracker that may go quiet. That is an ongoing tax with no offsetting capability gain on Laravel.

Support. GitHub issues only. No commercial backing, no security advisory process we can rely on, no documented deprecation policy. For a developer-only tool the blast radius is contained, but it still lands on our platform team's backlog.

Scaling. Not a runtime scaling concern — it is a per-developer interactive tool. The relevant scaling costs are developer-experience: booting a full kernel for each REPL session makes startup slow on large Symfony applications, and container-heavy introspection can be memory-hungry on developer laptops. Neither is a blocker; both are reasons not to add a second REPL toolchain to the estate.

Failure modes.

• Production exposure (critical): a REPL reachable in a production environment is an RCE vector. Mitigate with require-dev only, environment gating, and a CI assertion that the package is absent from production dependency graphs.
• Dependency deadlock: stale Symfony/PHP constraints blocking framework upgrades — the most likely practical failure, and one that forces migration on someone else's schedule.
• Bootstrap/config drift: container wiring that works locally but diverges across environments, producing confusing REPL failures.
• Silent abandonment: upstream stops responding to PHP releases; we discover it during an unrelated upgrade.

Ramp-up. Low for developers who already use Tinker or PsySH — the interaction model is identical, and the learning curve is measured in minutes. The real ramp-up cost is organizational: establishing the guardrail, documenting the standard, and retraining teams that have built muscle memory around $container->get(). Estimate one sprint of platform-team effort to inventory, convert, document, and close out the estate.

Bottom line. Low score, low adoption, wrong framework, and functionality we already get from a first-party package. Do not adopt for Laravel; convert existing Symfony usage to the standard toolchain and retire the dependency.