Package Changelog Laravel Package

Getting Started

1. Install as a dev dependency (it's a Composer plugin, not a Laravel service provider):

   composer require --dev ctf0/package-changelog
   

2. Allow the plugin — on Composer 2.2+ plugins are blocked by default, so add the entry Composer prompts for (or pre-add it):

   {
     "config": {
       "allow-plugins": {
         "ctf0/package-changelog": true
       }
     }
   }
   

   Without this the package installs silently but never runs.
3. Verify it's active by running an update that touches a package with a CHANGELOG.md:

   composer update some-vendor/some-package -W
   

   You should see the changelog excerpt printed after Composer's normal output.
4. Where to look first: the package's own README.md and any config/ or src/ files after install (vendor/ctf0/package-changelog/). Check whether it ships a publishable config (php artisan vendor:publish --tag=...) or is configured purely through composer.json extra. For a Composer plugin this is usually the latter.
5. First real use case: after a routine composer update, scan the printed changelog summaries to decide whether a minor/patch bump hides a breaking change — before you commit the lockfile.

Implementation Patterns

• Per-project, not global. Install it in the repos where you actually review dependency bumps. A global composer global require won't help teammates and won't travel with the project.
• Pair with an update workflow. Run composer update --dry-run first to see what would change, then a real composer update to get the changelog output, so you can review before merging.
• Treat it as a review aid in PRs. If your team commits composer.lock bumps, run the update locally, capture the changelog output, and paste the relevant entries into the PR description. This is the highest-value pattern for the package.
• Scope output with Composer flags. Combining with --no-interaction, --no-progress, or -q/-v lets you tune how much noise surrounds the changelog block. Use -vvv when debugging why a changelog didn't appear.
• Filter to the packages you care about. If the plugin exposes an ignore/allow list (check extra config or a published config file), restrict it to your framework and first-party deps so the output stays readable on large updates.
• CI integration (optional). In a pipeline that installs dependencies, the changelog output is generally noise; disable or skip the plugin there (e.g. via --no-plugins or a CI-specific composer.json) and keep it for local/interactive runs.
• Complement, don't replace, tooling. Use it alongside composer outdated, Dependabot/Renovate, and composer audit — it answers "what changed in this package", not "is this package safe/vulnerable".

Gotchas and Tips

• The allow-plugins trap is the #1 failure. No error, no output — the plugin just doesn't load. If nothing prints, check composer config allow-plugins first.
• Only works when a changelog exists. Packages without CHANGELOG.md (or with a differently named file — CHANGES.md, HISTORY.md, CHANGELOG.rst) will be skipped or print nothing. Don't assume the plugin is broken when it's just an uncooperative package.
• Changelog parsing is heuristic. Expect raw markdown, unreleased sections, or noisy historical entries to appear. It's a summary, not a curated diff — always confirm breaking changes against the package's actual release notes.
• Event timing. It hooks Composer's install/update package events, so it fires after each package is installed/updated, not at the very end. On multi-package updates the output is interleaved — read carefully or update packages one at a time when precision matters.
• --no-plugins disables it silently. Anything in your CI, Docker build, or scripts using --no-plugins will skip the changelog output entirely.
• --no-dev removes it from the run. Since it's a dev dependency, production installs won't execute it — that's desirable, but means you can't rely on it in a --no-dev context.
• Composer/PHP version constraints. This is a 2023-era plugin; pin it to a Composer major version you actually use and check composer.json require constraints if you're on PHP 8.3+/Composer 2.7+. If it misbehaves after a Composer upgrade, the plugin — not Composer — is usually the culprit.
• Debugging: rerun with -vvv to see plugin load/event messages; temporarily remove allow-plugins to confirm the plugin is what's producing the output.
• Don't rely on it for security. It surfaces changelog text, not advisories. Keep composer audit in your workflow.
• Low maintenance signal (16 stars, last release March 2023). Treat it as a nice-to-have convenience. If it breaks on a future Composer release, expect to patch it yourself or drop it — the fallback (composer update -v plus reading the package's CHANGELOG.md in vendor/) is trivial.