- How do I install php-conventional-changelog in a Laravel project?
- Install it as a dev dependency with composer require --dev marcocesarato/php-conventional-changelog. It requires PHP 7.1.3 or newer and Git 2.1.4 or newer, both well below what modern Laravel versions need. After installing, run vendor/bin/conventional-changelog from your project root, or wire it into Composer scripts so nobody has to remember the binary path.
- Is this a Laravel package with an Artisan command?
- No. There is no service provider, facade, publishable config, or Artisan command, because it is a standalone Symfony Console CLI that reads your local Git history. That is actually a reasonable shape for Laravel: it lives entirely in require-dev, never boots during a request, and has no coupling to the application container. You invoke it through vendor/bin/conventional-changelog or a Composer script.
- Which Laravel and PHP versions does this package support?
- The floors are PHP 7.1.3 and Git 2.1.4, comfortably below Laravel 11 and 12 requirements. The compatibility detail that matters is symfony/console, since Laravel pins a console major, so keep this package current because recent releases track Symfony 7 and 8. It has no Laravel framework constraint of its own.
- How does it decide the version bump for a release?
- It parses commit messages against the Conventional Commits spec and maps them onto SemVer. Fix commits produce a patch bump, feat commits produce a minor bump, and breaking changes, marked with a BREAKING CHANGE footer or an exclamation marker, produce a major bump. You can target specific tags, explicit ranges, or just the latest unreleased commits.
- How do I customize the changelog output and ignore certain commit types?
- Configuration lives in a config file at the repository root and covers templates, sections, commit filters, and ignored types. The default ignore list drops perf, refactor, and revert commits, so review that before publishing customer-facing release notes. A positional path argument lets you scope generation to a subdirectory, which is the escape hatch for monorepo setups.
- How do I run it from Composer scripts?
- Add entries under the scripts key of composer.json, for example changelog pointing at conventional-changelog, plus release variations for patch, minor, and major. Developers then run composer changelog or composer release:minor instead of memorizing binary flags. Keep the scripts thin and let the config file hold the real settings.
- Why is my changelog missing commits or computing the wrong version in CI?
- Almost always because CI cloned shallowly. With fetch-depth 1 there are no tags in the checkout, so the tool has no correct version base and miscomputes ranges. Set fetch-depth 0, or explicitly fetch tags, in GitHub Actions or GitLab CI before the release step runs.
- Can it create commits and tags automatically, and is that safe in CI?
- Yes. Flags such as commit, amend, commit-all, and no-verify let one command create commits, write tags, and bypass Git hooks. In CI with a write-scoped token that is a real blast radius, so restrict the token, avoid commit-all on a dirty working tree, and confirm whether the tool pushes to the remote or only creates refs locally.
- Is the GPL-3.0 license a problem for a commercial Laravel application?
- It is GPL-3.0, which is the biggest adoption blocker for many commercial teams. Because it is a dev-only build tool and is not distributed as part of your application, most legal teams will approve it, but that is a legal judgment rather than an engineering one. Get written sign-off before it lands in composer.json on a commercial product.
- Does it work with squash-merge workflows and tag-based versioning?
- Squash merges collapse branch history into a single commit, so the PR title becomes the message the tool parses, which works only if your team writes conventional PR titles. Verify against a real release, because squashing can discard the individual feat and fix commits the changelog depends on. Also confirm whether the tool writes a version into composer.json or derives everything from tags, since that determines your source of truth before adoption.