Composer Update Helper Laravel Package

Getting Started

Install it as a dev-only dependency first:

composer require --dev nowo-tech/composer-update-helper

For a Symfony app, check whether Flex auto-registers the bundle. If not, add it to config/bundles.php, then clear the cache:

php bin/console cache:clear

Look first at the README, src/Command/, and src/DependencyInjection/Configuration.php. The command name is the main thing to confirm; discover it with:

php bin/console list | grep -i composer
php bin/console list nowo

A good first use case is a stale application branch with a handful of outdated direct dependencies. Run the helper, review the generated composer require ... lines, and apply only patch/minor upgrades first. Treat the output as an upgrade plan, not as something to pipe blindly into a shell.

If you are not using Symfony, check composer.json for a bin entry or documented Composer script. The package advertises framework-agnostic use, but the Symfony console command is the primary integration point to verify.

Implementation Patterns

Upgrade-sprint workflow. Run the helper on a clean branch, capture the output, and classify commands into patch, minor, and major upgrades. Apply patch/minor commands in a batch, run the test suite, then handle majors one at a time. This keeps dependency conflicts and behavioral changes easy to isolate.

Composer script alias. Once you know the command name, wire it into composer.json so the team does not need to remember it:

{
  "scripts": {
    "deps:plan": [
      "@php bin/console <command> --no-interaction"
    ]
  }
}

Then run composer deps:plan during dependency-review sessions.

CI advisory job. Schedule the helper in CI and write its output to an artifact or job summary. Do not auto-apply the generated commands. Use it to surface “these constraints are behind” and let a human decide whether the upgrade belongs in the current sprint.

Ignore-list-driven upgrades. If the bundle exposes configuration for ignored packages, use it for dependencies blocked by PHP version, extensions, or internal compatibility constraints. This makes the generated plan actionable instead of noisy.

PR workflow. Include the generated command list in the PR description, then commit only the resulting composer.json and composer.lock changes. Reviewers can see exactly which constraints were intended to move.

Non-Symfony projects. Prefer invoking any documented binary from vendor/bin or a Composer script. Do not assume bin/console exists outside Symfony; verify the package’s framework-agnostic entry point first.

Gotchas and Tips

• Review every generated command. composer require vendor/package:^2.0 changes root constraints; it is not the same as updating a transitive dependency.
• Watch dev dependencies. Generated commands may not preserve --dev for packages currently in require-dev. Add it manually when needed.
• Avoid adding transitive packages to root. If a package is only outdated transitively, prefer composer update vendor/package --with-dependencies instead of composer require, unless you intentionally want it as a direct dependency.
• Quote version constraints in shells. Caret constraints can be interpreted by cmd.exe or other shells. Use single quotes where possible: composer require 'vendor/package:^2.0'.
• Do not batch major upgrades. Run one major at a time, read the changelog, and commit separately.
• Pin the package version. With very low adoption, treat it as an internal helper: pin a known tag/commit, keep it in require-dev, and avoid production dependency on it.
• Check Composer availability and auth. The helper likely relies on composer outdated; private repositories need credentials in the environment running it.
• Use --no-ansi when capturing output. If you pipe or parse the output, disable ANSI formatting and prefer JSON or plain text options if available.
• Clear Symfony cache after config changes. Bundle configuration and container changes will not appear until the cache is rebuilt.
• Prefer configuration over inheritance. Many modern bundles use final classes; use documented ignore/config options or decorate the command rather than extending it.
• Release metadata looks unusual (future-dated release), so verify the tag you install and rely on your own smoke test rather than assuming the latest metadata is accurate.