madalynn/plum-bundle
Symfony bundle that integrates the Plum library into Symfony applications, registering its services in the container and exposing configuration for quick setup. Provides a convenient starting point for using Plum in Symfony projects, with autoconfiguration and sensible defaults to reduce boilerplate...
Architecture fit. This is a Symfony2 bundle, not a Laravel package. It ships a bundle class extending Symfony\Component\HttpKernel\Bundle\Bundle, wires services through Symfony's DI container, and exposes deploy commands via the Symfony Console. Laravel's service provider / facade / Artisan kernel model has no compatible boot path for a bundle class — nothing here can be composer required into a Laravel app and started. The only reusable assets are the pattern (wrapping a deploy CLI in framework console commands) and Plum itself as a standalone tool.
Integration feasibility. Low. Two bad options: (a) stand up a parallel Symfony2 application purely to host the deploy commands — a large infrastructure tax for a thin wrapper — or (b) port the bundle's service wiring into a Laravel service provider, which is effectively a rewrite of a 26-star, zero-dependent package. Neither is proportionate. If Plum's release model is wanted, invoke the Plum binary/PHAR directly from CI or a Makefile and skip the bundle entirely.
Technical risk. High and mostly exogenous. Symfony2 reached end of life in November 2018; the bundle's constraints pin PHP to 5.x/early 7.x, which conflicts with any current Laravel release (10/11 require PHP 8.1+). Composer either refuses resolution or forces an application-wide downgrade. Zero dependents and 26 stars mean no production validation and no downstream bug pressure — defects surface first in our environment.
Key questions.
Stack fit. None. Laravel expects service providers, publishable config, and Artisan commands; this package delivers none of those. The 0.31 health score is consistent with code that is alive on paper but functionally inert for a modern PHP application.
Migration path. If deploy capability is genuinely needed, sequence it as: (1) confirm Plum's standalone CLI runs on the target PHP version and hosting topology; (2) express the deploy as a versioned script (Plum config, or a Deployer/Envoy recipe) checked into the repo; (3) wire that script into CI (GitHub Actions, GitLab CI) as a gated job; (4) only consider a Laravel-native wrapper once many apps need the same recipe. Do not migrate to this bundle at any step.
Compatibility. Assume incompatible until proven otherwise. Realistic blockers: PHP version constraints, Symfony 2.x component pinning, and reliance on the Symfony Console event/dispatcher API. Even a lucky install leaves two frameworks in one deploy path.
Sequencing. Treat this as a timeboxed spike (one day) whose deliverable is a documented decision, not working code. Preferred order of alternatives: managed platform deploy (Vapor, Envoyer, Forge, or the PaaS already in use) → Deployer/Envoy recipes → Plum CLI standalone → a small in-house Artisan command wrapping the chosen tool → fork/port this bundle (last resort, effectively never).
Maintenance. Effectively unmaintained for our purposes. Adopting it transfers ownership of Symfony2 internals to our team, including security patching of an EOL framework — a standing cost with no offsetting benefit, since the deploy logic lives in Plum, not the bundle.
Support. No vendor, no SLA. Community support is a 26-star repository; expect issues to go unanswered. Internal escalations will land on whoever volunteered to own deploy tooling, with no upstream backstop.
Scaling. Deploy tooling scales with the number of applications and environments, not request volume. A single bundle-shaped integration does not compose into a multi-app platform; a shared CLI recipe or CI template does. Choosing the bundle actively works against standardizing deploys across a growing Laravel portfolio.
Failure modes. Characteristic failures are quiet and expensive: deploys run from developer laptops against production because the tool is a local CLI rather than a CI gate; partial deploys with no rollback semantics beyond what Plum provides; config drift between host configuration and Laravel .env; and Composer resolution breakage on the next PHP upgrade, blocking routine dependency updates until the deploy path is excised. The absence of dependents means none of these have been shaken out by anyone else first.
Ramp-up. Near zero for the bundle, because there is nothing worth learning. The real ramp-up is Plum itself — small and productive within a day — plus the CI integration and rollback documentation. Budget effort there, not on the package. TPM call: do not adopt. Record the decision, evaluate Plum as a standalone CLI if self-hosted deploy is a genuine requirement, and otherwise route to the managed deploy option already in the stack.
How can I help you explore Laravel packages today?