Upgrade Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the premise needs correcting first. modera/upgrade-bundle is a Symfony bundle, not a Laravel package. Its integration surface is the Symfony bundle contract (Bundle subclass, DependencyInjection extension, container-aware services, Symfony console commands). Laravel has no equivalent bundle lifecycle, so there is no drop-in path — adopting it means either a translation layer (service provider + command wrappers) or extracting the logic into framework-agnostic code. Before any of that, confirm with the requesting team that this wasn't selected by name match rather than stack match, because the framing is a Laravel/PHP evaluation of a Symfony-only artifact.

Functional scope is narrow and largely superseded. The bundle exists to run ordered, version-aware upgrade routines after dependency updates — a CLI-time orchestration concern, not a runtime one. That problem is real and recurs, but the modern toolkit covers most of it: Composer post-update-cmd scripts, Symfony Flex recipes, Doctrine/Laravel migrations, and Rector for automated code-level upgrades. The bundle's only genuinely differentiating capability is cross-package ordering of upgrade steps, and that is the one thing worth evaluating on merit.

Integration feasibility — low. Last release 2016-06-10, archived and read-only, 0 stars, 0 dependents. The code targets PHP 5.6/7.0 and Symfony 2.x/3.x: container-aware base classes, getContainer() access patterns, pre-4.0 event dispatcher signatures. None of that runs cleanly on modern Symfony or PHP 8.x without modification. Zero dependents means zero field validation — no evidence anyone has run this in production, and no community migration notes.

Technical risk — high and asymmetric. Unpatched archived code in the dependency graph is a standing security and compliance finding, and Composer will install it without complaint. The upside is small (a thin orchestration layer), the downside is a permanent fork obligation. Cost of ownership exceeds cost of reimplementation.

Key questions for the requesting team:

• What specific upgrade pain are we solving — ordered cross-package steps, data migrations, or config drift?
• Is this a Laravel shop or a Symfony shop? If Laravel, this package is out of scope by construction.
• Has anyone read the source to confirm the orchestration logic is worth extracting versus rewriting (~ a few hundred lines)?
• What is the blast radius if an upgrade step runs twice or partially? What state tracking already exists that we'd be replacing?
• Who owns the fork if we take one — named engineer, not team?

Integration Approach

Stack fit — none as-is. No Laravel service provider, no facade, no publishable config. A wrapper would be bespoke glue around unmaintained internals: we inherit the maintenance burden without inheriting API stability.

Recommended path — extract the concept, not the code. Read the source once; document the upgrade-ordering model (version-to-step mapping, how applied steps are recorded, how ordering resolves across packages); reimplement natively:

• Laravel: an Artisan command plus a package_upgrades ledger table, invoked from composer.json post-update-cmd. Roughly a sprint including tests.
• Framework-agnostic: a small Composer plugin if the need spans non-Laravel repos.

One design decision to make deliberately: the bundle assumes upgrade scripts ship inside each package, coupling packages to the orchestrator and to our release process. Decide between that model and a central, version-keyed script registry before building.

Fallback path — private fork, never public install. Vendor the archived source internally, pin the commit, apply PHP 8 / framework patches, and gate it behind an internal package name so it can't be pulled from Packagist. Justified only if the read-through shows materially more complexity than expected.

Compatibility. Any fork must be validated against the current PHP minor and the framework's supported major. Expect breakage in service wiring, console command signatures, and event dispatch. Budget a compatibility spike before committing to the fork.

Sequencing.

1. Confirm target framework and the concrete upgrade failure being solved (1 day).
2. Source read-through and logic-extraction notes (1–2 days).
3. Spike the native reimplementation behind a flag on one package (1 sprint).
4. Decide fork vs. build based on spike findings.
5. Only then touch composer.json in production services.

Nothing here is blocking, and the current state (no dependency) is safe — do not sequence this ahead of higher-priority work.

Operational Impact

Maintenance — fully ours, permanently. Archived, read-only, single-maintainer project with no successor. No upstream to file issues against, no CVE feed, no release cadence. Every future PHP or framework upgrade converts into an internal patch obligation. Bus factor is effectively one, and that one has moved on.

Support. No vendor, no community, no dependents to consult. Internal tribal knowledge becomes the only support channel — which argues for reimplementation, since a small in-house module is supportable by the team that wrote it.

Scaling. Runtime impact is nil: work happens at install/upgrade time in CLI context, not per-request. The scaling concern is organizational — every service on the fork must be patched and re-released in lockstep as the platform moves.

Failure modes to design against:

• Partial application — a step fails midway with no transaction boundary, leaving package state inconsistent.
• Non-idempotency — a re-run duplicates data migrations or seeds; each step must be individually re-runnable.
• Silent no-op — version comparison mismatches (string vs. semver, prerelease tags) skip steps with a success exit code.
• Ordering ambiguity — two packages claiming the same target version with no deterministic tiebreak.
• Composer interaction — post-update hooks that mutate files can conflict with composer.lock verification in CI.

Any reimplementation must record applied steps in a durable ledger and fail loudly, not silently.

Ramp-up. Low for the code (small surface), high for the domain (why the ordering rules exist, which packages rely on them). Ramp-up is front-loaded into the extraction read-through and is not recovered if we abandon a fork — another argument for building natively from documented behavior.

Bottom line for the roadmap: do not adopt modera/upgrade-bundle. Treat it as a design reference. The underlying need — customers on old versions upgrading painfully, generating tickets and failed-upgrade incidents — is legitimate; the artifact is not viable. If that pain is measurable, fund a small internal upgrade runner as a platform capability.