ctf0/package-changelog
A Laravel package for working with package changelogs. It helps you track release notes and version history, making it easier to present clear update details to users from within your application, whether for admin dashboards, documentation, or release notes pages.
Architecture fit
ctf0/package-changelog is a Composer-lifecycle utility, not an application dependency. It hooks the install/update flow (post-package-install / post-package-update, or an artisan command invoked via Composer scripts) and prints or forwards the changelog entries of packages that just moved. Architecturally it belongs in the developer-tooling tier alongside PHPStan, Pint, or composer-unused — it does not sit in the request path, holds no runtime state in your app, and should never be a production dependency. Fit is therefore narrow and clean if your goal is "surface what changed in vendor code at the moment it changes" for supply-chain awareness or change-review discipline. It is a poor fit if you want structured, queryable dependency-change history — this emits human-readable console/Slack output, not an auditable record.
Integration feasibility
Low effort on paper: install as require-dev, publish the config, add the Composer script hook, optionally set a Slack webhook and a GitHub token for release lookups. Two feasibility unknowns dominate. First, whether it registers as a Composer plugin or relies on plain scripts — a Composer 2 plugin requires an allow-plugins entry, which is a governance decision in most orgs and will break silently on locked-down CI. Second, whether it fails open or closed: if a missing CHANGELOG.md, a network timeout, or a GitHub rate limit returns a non-zero exit code, it takes your install down with it. That single behavior determines whether this is a 5-minute pilot or a non-starter.
Technical risk
High for the maturity signals shown: 16 stars, 0 dependents, last release March 2023, single maintainer, MIT. Zero dependents means no downstream validation — you would be among the first real users, so edge cases are yours to find. Changelog parsing is intrinsically brittle (inconsistent heading formats, monorepo packages, absent files, Unreleased sections), and the GitHub-release fallback adds an unauthenticated-API rate limit (60 req/hr) plus token-handling surface. Version drift against current PHP/Laravel majors is unproven; the 2023 release date predates several Laravel and PHP minor cycles.
Key questions
allow-plugins acceptable here?php / illuminate/support constraints vs. our current matrix?Stack fit
Reasonable only in a Laravel/PHP shop already standardized on Composer and comfortable with require-dev tooling. Value scales with dependency churn: services with 80+ packages and frequent composer update cycles get genuine signal; a five-dependency app gets noise. The Slack relay is the most interesting capability for platform teams wanting visibility into what a routine dependency bump actually changed, but it is also the piece with the most operational side effects.
Migration path
There is no incumbent to migrate from — this is net-new adoption, so treat it as an experiment, not a migration. If you already have an internal "diff the lockfile and summarize" script, do not migrate to this; keep your script and borrow the changelog-extraction idea. Recommend a one-repo spike: install pinned to the exact released version, run a composer update with a handful of outdated packages, and record (a) exit codes on failure injection, (b) output verbosity, (c) whether Composer 2 flags it.
Compatibility
Verify before committing: Composer 1 vs. 2 hook semantics, PHP constraint ceiling, whether it hard-requires laravel/framework (which would drag framework into contexts that only need illuminate/support), and behavior under --no-dev installs in CI. Pin an exact version — a ^ constraint on an unmaintained package invites an unreviewed patch landing in your builds.
Sequencing
Maintenance Effectively unmaintained. Assume you own it. Mitigating factor: the surface is small enough that a fork is a realistic option rather than a rewrite, but that still means internal ownership, a fork namespace, and periodic rebases. Add it to a dependency-watch list keyed to the next Composer or PHP major.
Support No vendor, no SLA, GitHub issues only, single maintainer who may be unreachable. Any org-wide rollout needs a named internal owner before it spreads; without one it becomes orphaned tooling that breaks a build six months later and gets ripped out under pressure.
Scaling
Two real limits. Output volume: it fires per changed package, so a large composer update produces a wall of text that buries genuine Composer errors — mitigate with include/exclude lists. Upstream limits: unauthenticated GitHub API calls cap at 60/hour and will silently truncate release-note lookups on a busy CI fleet; Slack webhooks will rate-limit and flood channels. Cost per invocation is negligible; cognitive cost is not.
Failure modes
Missing or malformed CHANGELOG.md; GitHub rate limiting or no network in air-gapped CI; non-zero exit blocking composer install; token committed to a published config file; noisy output masking real resolution errors; silent no-op after the next Composer major (worst failure — teams believe they have change visibility they no longer have).
Ramp-up Developer ramp-up is minutes: install, publish config, read a short README. Platform-owner ramp-up is the real cost — understanding the hook mechanism, writing the failure-injection tests, and being prepared to fork. Budget a day of engineering evaluation before any wider commitment, and treat the 0.2 score and zero dependents as evidence to validate the failure behavior yourself rather than accept the README's word.
How can I help you explore Laravel packages today?