Weave Code
Upgrade Bundle Laravel Package
modera/upgrade-bundle
Modera Upgrade Bundle helps you migrate applications between major versions with less friction. It provides upgrade routines, compatibility checks, and guided migration steps so you can move to newer releases safely and with minimal manual effort.
[READ-ONLY] Bundle simplifies upgrading procedure of Composer packages.
Frequently asked questions about Upgrade Bundle
- Is modera/upgrade-bundle a Laravel package?
- No. modera/upgrade-bundle is a Symfony bundle, not a Laravel package. It integrates through Symfony's bundle lifecycle, dependency injection extension, container-aware services, and console commands. Laravel has no equivalent bundle contract, so there is no drop-in installation path; using it in Laravel would require a custom wrapper or extracting the orchestration logic.
- What upgrade problems does modera/upgrade-bundle solve?
- It runs ordered, version-aware upgrade routines after Composer dependency updates, so applications can move between major versions with fewer manual steps. The real value is cross-package ordering of upgrade steps: mapping versions to steps and recording which steps have run. That is a CLI-time orchestration concern, not a runtime feature, and much of the surrounding need is now covered by Composer scripts, framework migrations, Symfony Flex recipes, and Rector.
- How do I install modera/upgrade-bundle?
- In a legacy Symfony 2.x or 3.x application on PHP 5.6 or 7.0, install it with Composer and register the bundle in AppKernel as the README describes. The package was last released in 2016 and is archived read-only, so installation is only realistic for historical projects or a pinned internal fork. There is no supported Laravel installation path because the package has no Laravel service provider or facade.
- How do I configure modera/upgrade-bundle in a Symfony app?
- Configuration follows Symfony's bundle conventions: register the bundle, let its DependencyInjection extension load services, and invoke its console commands as part of your upgrade process. There is no publishable Laravel config file, no facade, and no Artisan integration. Any wrapper around it would be bespoke glue over unmaintained internals, so document the version-to-step mapping and ordering rules before building one.
- Does modera/upgrade-bundle work with Laravel 10 or Laravel 11?
- No. The last release targets PHP 5.6/7.0 and Symfony 2.x/3.x, with container-aware base classes and pre-4.0 event dispatcher signatures. It will not run cleanly on PHP 8.x or modern Symfony without patching, and it has no Laravel 10 or Laravel 11 support. For Laravel, build an Artisan command plus a package_upgrades ledger table instead.
- Is modera/upgrade-bundle still maintained?
- No. The repository is archived and read-only, the last release was 2016-06-10, and it has 0 stars and 0 dependents. That means no field validation, no community migration notes, and no security patches. Treat it as unmaintained code in the dependency graph, which is a standing compliance finding.
- What are the production risks of using modera/upgrade-bundle?
- The main risks are unpatched archived code, obsolete PHP and Symfony assumptions, and unclear behavior if an upgrade step runs twice or partially. Because there are zero dependents, there is no evidence anyone has run it in production at scale. The upside is a thin orchestration layer; the downside is a permanent fork obligation, so cost of ownership likely exceeds reimplementation.
- How should I test an upgrade routine before running it in production?
- Test the ordering model first: version-to-step mapping, how applied steps are recorded, and how ordering resolves across packages. Run routines against a disposable database and a pinned dependency set, and verify idempotency by running the same step twice and simulating a partial failure. A native replacement should use an explicit ledger, such as a package_upgrades table, so state is auditable and safe to retry.
- What are the best alternatives to modera/upgrade-bundle for Laravel?
- For Laravel, use Composer post-update-cmd scripts, Laravel migrations, and Rector for automated code upgrades; add a small Artisan command and a ledger table if you need ordered steps. For Symfony, Flex recipes and Doctrine migrations cover most of the same ground. If cross-package ordering is genuinely required, build a small Composer plugin or central version-keyed script registry rather than adopting this bundle.
- Should I fork modera/upgrade-bundle or reimplement it?
- Prefer extracting the concept, not the code. Read the source once, document the upgrade-ordering model, and reimplement natively in roughly a sprint including tests; that avoids inheriting an unmaintained dependency. Fork only if the read-through shows materially more complexity than expected, and then keep it private, pin the commit, patch PHP 8 and framework compatibility, and name a single engineer as owner.
Weaver
How can I help you explore Laravel packages today?