- What does markwalet/laravel-changelog actually do?
- It's a Laravel package for managing your application's changelog in version-controlled source files instead of one monolithic CHANGELOG.md. Releases and their changes live in simple files that are read through a facade, so you can surface version history in your UI, API, or docs. It ships artisan commands for creating and rendering releases, requires no database, and is designed to keep the changelog out of the path of merge conflicts.
- How do I install markwalet/laravel-changelog in a Laravel app?
- Install it as a dev dependency with composer require --dev markwalet/laravel-changelog. The package targets PHP 8.2+ and Laravel 12+, so confirm your local, CI, and build environments meet that baseline before running composer update. Publish the config if you need to change where changelog sources live, then scaffold your first release with the package's artisan commands. Commit the config and changelog files so the whole team generates from the same source.
- Does markwalet/laravel-changelog support Laravel 10 or 11?
- No. Version 1.13.0 requires Laravel 12 and PHP 8.2 or newer, and it dropped support for Laravel 10 and 11 in what is technically a minor release. If you're still on Laravel 10 or 11, pin the package to <1.13.0 and treat the framework upgrade as a prerequisite for the bump. Don't run a blanket composer update that lets this dev package pull your application forward.
- Is markwalet/laravel-changelog dev-only, or does it need a database?
- It's developer tooling, so install it with --dev: it exposes artisan commands and reads/writes changelog files, with no runtime middleware, migrations, queues, or database tables involved. That keeps the blast radius small, because failures show up in a terminal or CI job rather than in a customer request. You still want it present in build containers that run the changelog commands, but it has no business being a production dependency.
- How do I display the changelog in my application UI or API?
- The package exposes a facade that reads your changelog sources and returns releases and their changes as structured data. Alias or inject the facade in a controller, API resource, or Blade view and map the results into whatever shape your front end expects. Because the data comes from committed files rather than the database, there's no query cost or migration to worry about, and you can cache the rendered output if needed.
- How does this package prevent merge conflicts on the changelog file?
- Instead of every branch appending to the same CHANGELOG.md, each release is stored in its own file, so two branches adding different releases touch different files and Git has nothing to conflict over. The package then reads all of those files and assembles the changelog for you. The payoff is that release notes can be written on the feature branch that ships them, while the change is still fresh.
- How do I test code that reads the changelog through the facade?
- Because the changelog is read from files on disk, point the package config at a fixture directory in your test suite and assert against the releases and entries the facade returns. If your code wraps the facade, swap it for a mock or bind a fake in the container. For command tests, assert on the integer exit codes explicitly rather than assuming every invocation succeeds.
- Why does a malformed changelog file only produce a warning in 1.13.0, and how do I fail CI on it?
- In 1.13.0, malformed source input produces a warning instead of throwing an exception, which changes the failure signature that scripts and monitoring may key off. Verify whether the command still exits non-zero in that case before relying on it to break a build; if it doesn't, add an explicit validation step or grep the output for the warning text in CI. Then update any pipeline that previously expected an exception.
- Should I pin markwalet/laravel-changelog to an exact version or use a caret constraint?
- If you're on Laravel 12 and PHP 8.2+, a caret constraint is reasonable for a dev-only package. If you're on Laravel 10 or 11, pin to <1.13.0 and record the framework upgrade as tech debt with a target date. Given that 1.13.0 removed framework support in a minor release, teams with strict reproducibility needs should pin exact versions and commit composer.lock so CI resolves the same set every run.
- What are the alternatives to markwalet/laravel-changelog?
- Manual Keep a Changelog files, conventional-changelog, git-cliff, and release-drafter all solve adjacent problems, though most generate notes from commits or pull requests rather than maintaining curated release files. markwalet/laravel-changelog is aimed at Laravel teams who want hand-written releases in version control plus a facade for reading them in-app. If you already generate notes from commit history and never display them in your UI, a git-based tool may be a lighter fit.