- What does the kylekatarnls/update-helper Composer plugin actually do?
- It is a Composer plugin that lets a package ship its own update script, which Composer executes automatically after install or update. Maintainers use it to migrate configuration files, patch code, or print an upgrade notice when a release contains breaking changes. It only hooks into Composer's install and update lifecycle, so it never touches your Laravel application at runtime. The point is to keep upgrade logic inside the package that owns it instead of forcing consumers to read release notes and act manually.
- How do I install and configure update-helper in a package or Laravel project?
- Run composer require kylekatarnls/update-helper in the library that wants to distribute the notice, or add it to require-dev for a single application. The package then declares its update message or script under the extra section of its composer.json, and consumers simply run composer install or composer update as usual. There is no service provider, no config publishing, and no application code to write. For a Laravel app you get the behaviour automatically because Composer runs below the framework.
- Do I need to enable allow-plugins for update-helper in Composer 2.2+?
- Yes. Composer 2.2 and later block plugins by default until they are listed in config.allow-plugins, so consumers will see a prompt or an error until the plugin is allowed. This is a process change rather than a code change, which means it needs to be documented in your onboarding guide and baked into CI images. If you cannot get consumers to allow plugins, the notice will never fire.
- Will the update-helper prompt block CI pipelines or composer install --no-interaction?
- It can if the interaction is not handled correctly, and a prompt that blocks an unattended pipeline is a hard failure. Test explicitly with --no-interaction, in a read-only CI environment, and with --no-dev before rolling the package out. The plugin should degrade to a silent no-op when input is not possible. Treat any blocking behaviour as a release blocker, not a nice-to-have.
- Is kylekatarnls/update-helper compatible with Composer 2 and current Laravel versions?
- It operates purely at the Composer layer, so it has no Laravel version matrix and no framework coupling to worry about. The real compatibility question is Composer itself: the last tagged release dates from April 2020, which predates Composer 2.2's allow-plugins default and current plugin API expectations. Verify the declared composer-plugin-api constraint empirically against the Composer versions on your dev machines and CI images rather than assuming it works. Mixed Composer 1 and Composer 2 fleets are the main hazard.
- Is update-helper still maintained, and what are the risks of depending on it?
- It is a single-maintainer project, well proven because it powers Carbon's own upgrade prompt, but not institutionally backed and with no release since 2020. The supply chain consideration is real: as a transitive dependency it lands in every consumer's install graph and executes code during composer install, so a security and code review is warranted. Define a rollback path up front, whether that is pinning a version, removing the plugin, or forking it, since its surface area is small enough to fork if maintenance lapses.
- When is update-helper worth using and when is it overkill?
- It pays off for distributed consumers you cannot email directly: public packages, or cross-team internal packages with many independent consumers. It complements SemVer and a CHANGELOG rather than replacing them, delivering the message at the exact moment a developer touches composer.json. For a small set of first-party apps upgraded in lockstep, the benefit is marginal and plain release notes are usually enough. Pilot it on one package with a real upcoming major before standardising it.
- What are the alternatives to update-helper for warning developers about breaking changes?
- The baseline is disciplined SemVer, a clear CHANGELOG, a written upgrade guide, and Composer's abandoned or replace metadata combined with composer audit. Native Composer script events in a root composer.json can also run migrations, but only for that project, not for every consumer. Update-helper adds a delivery channel at update time; it should not be the only signal. Many teams end up using it as a supplement and keeping the changelog as the source of truth.
- Does update-helper run with --no-scripts, --no-dev, offline installs, or when nothing changes?
- Those flags and scenarios change which Composer events fire, so behaviour must be verified rather than assumed. A notice that fires on every no-op locked install quickly becomes noise, and one that silently disappears under --no-scripts may never reach the developer who needs it. Test each combination in a scratch project before shipping a release that depends on the notice. Also make sure the message content stays accurate, because stale terminal output turns into support tickets with no telemetry to detect it.
- How should I test an update-helper update script before releasing a breaking change?
- Create a scratch project that requires the previous major version, then bump it and run composer update both interactively and with --no-interaction to confirm the script runs, exits cleanly, and is idempotent on repeat runs. Repeat inside a CI-like container with no TTY to catch blocking prompts. Pilot the whole flow on one internal package with a real upcoming major and measure whether consumers upgrade faster or file fewer support requests. Only then standardise the extra block schema so notices stay consistent and reviewable in pull requests.