Download the PHP package rector/jack without Composer
On this page you can find all versions of the php package rector/jack. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package jack
Short Description Swiss knife in pocket of every upgrade architect
License MIT
Informations about the package jack
Jack: Raise your Dependencies Safely
Experimental: Jack is an experimental project under active development. It is not yet stable, may contain bugs or undergo breaking changes. It's build it in the open with the community feedback.
In real world, "jack" is a tool that helps to raise your heavy car one inch at a time. So you can fix any issues down there and drive safely on journeys to come.
In Composer world, Jack helps you to raise dependencies one version at a time, safely and steadily.
Say goodbye to unnoticed, years-old dependencies!
Why Jack?
Manually upgrading dependencies can be daunting, especially when tackling multiple outdated packages at once. Large upgrades often lead to errors, compatibility issues, and costly delays.
Jack automates and simplifies this process by:
- Monitoring outdated dependencies via CI.
- Gradually opening up package versions for safe updates.
- Prioritizing low-risk updates (e.g., dev dependencies).
Install
Rector Jack is downgraded and scoped. It requires PHP 7.2+ and can be installed on any legacy project.
Then, pick from three powerful commands:
1. Too many Outdated Dependencies? Let CI tell us
Postponing upgrades often results in large, risky jumps (e.g., updating once a 3 years). Jack integrates with your CI pipeline to catch outdated dependencies early.
Run the breakpoint
command to check for outdated major packages:
↓
If there are more than 5 major outdated packages, the CI will fail.
Use --limit
to raise or lower your bar:
This ensures upgrades stay on your radar without overwhelming you. No more "oops, our 30 dependencies are 5 years old" moments!
It's safer to start upgrading dev packages first. You can spot them like this:
2. Open up Next Versions
We know we're behind the latest versions of our dependencies, but where to start? Which versions should be force to update first? We can get lot of conflicts if we try to bump wrong end of knot.
Instead, let Composer handle it. How? We open-up package versions to the next version:
This command opens up 5 versions to their next nearest step, e.g.:
Then we run Composer to do the work:
If no blockers exist, Composer will update packages to their next version.
To change the number of packages, use --limit
option:
To upgrade only specific group of packages, use --package-prefix
option:
To preview changes without modifying composer.json
, add --dry-run
.
Do you want to play it safe? Try low-risk dev packages first:
3. Raise to Installed Versions
Sometimes, we get to an opposite situation. Our dependencies are quite new, but our composer.json
is a outdated:
Here we can see that:
illuminate/container
12.0 is allowed, but we already use 12.14symfony/finder
6.4 is allowed, but we already use 7.2
If someone runs composer update
, they might get unnecessary older dependencies than we can handle. Also, we're self-deprecating out project by signalling old dependencies we don't even use.
Instead, we should raise our composer.json
to the installed versions:
That's exactly what following command does:
To see changes first without applying, add --dry-run
.
Happy coding!