Weave Code
Composer License Checker Laravel Package
lendable/composer-license-checker
A dev tool that checks Composer dependency licenses against configurable rules to ensure open source compliance and reduce legal risk. Define allowed licenses, vendors, and packages in a PHP config file, then run it in CI. Uses installed.json or composer licenses as its data source.
Composer License Checker audits your Composer dependencies' licenses against configurable rules, helping you stay compliant with open source licenses and minimize legal risk. Define allowed licenses, vendors, and packages in a simple .allowed-licenses.php file, then run the checker locally or in CI.
- Flexible rules — allow licenses, entire vendors, or specific packages.
- Two providers — parse
installed.jsonor usecomposer licenses. - CI-friendly — easy to integrate into automated pipelines.
- Custom config path via
--allow-file. - No Composer required with the default JSON provider.
Frequently asked questions about Composer License Checker
- How do I install the Composer license checker in a Laravel project?
- Install it as a dev dependency with composer require --dev lendable/composer-license-checker. The package has no Laravel service provider, so there is nothing to register in config/app.php or bootstrap/providers.php. After installation the binary is available at vendor/bin/composer-license-checker, ready to run locally or in CI.
- Which PHP and Laravel versions does lendable/composer-license-checker support?
- Version 1.4.1 requires PHP 8.4 or newer and now permits PHP 8.6, so it fits any Laravel release running on that runtime. Projects still on PHP 8.1 to 8.3, which includes many Laravel 10 and 11 installations, cannot install it without upgrading PHP or pinning an older release. The package itself has no framework constraints and runs wherever Composer runs.
- How do I create the allowed licenses configuration file?
- Create a .allowed-licenses.php file in your project root that returns a LicenseConfigurationBuilder instance. Call addLicenses() with the SPDX identifiers you permit, addAllowedVendor() to whitelist everything from a vendor such as your own company, and addAllowedPackage() for one-off exceptions. Finish the chain with build(). If you need the file elsewhere, point to it with the --allow-file option.
- How do I run the license check in GitHub Actions or GitLab CI?
- Add a step that runs ./vendor/bin/composer-license-checker after composer install, or expose it as a Composer script such as composer check-license. The command exits non-zero when a dependency falls outside your rules, which fails the build and blocks the merge. The README recommends exactly this: build it into your pipeline so license drift is caught automatically.
- Should I use the installed.json provider or the composer licenses provider?
- The default provider is json, which parses the installed.json file Composer writes into vendor/composer. It does not require the Composer binary in the environment, which is convenient in slim CI images, but the file is internal to Composer and its schema could change. If you hit parsing problems, switch with the --provider-id option to use the composer licenses command instead.
- How do I allow a specific package or vendor regardless of its license?
- Use addAllowedVendor() in the configuration builder to allow any license coming from a vendor, which is typical for your own first-party packages. Use addAllowedPackage() to whitelist a single package such as vendor_name/foo_bar no matter what it is licensed under. Both are evaluated as part of the same rule set as the license allowlist, so keep them narrow and documented to preserve the value of the check.
- Can I run the license checker as a PHPUnit listener or pre-commit hook?
- Yes. The tool is a plain CLI binary, so it can be invoked from a Composer script, a post-install hook, a PHPUnit listener, or a Git pre-commit hook managed by tools like CaptainHook or GrumPHP. A pre-commit hook gives the fastest feedback, but the authoritative gate should still be the CI step. None of these approaches require Laravel-specific wiring.
- Why does the checker flag packages that look correctly licensed?
- Dual-licensed packages and packages using SPDX expressions or non-standard license strings can produce false positives, because the recorded value does not literally match an entry in your allowlist. Add the exact identifier reported by composer licenses to addLicenses(), or use addAllowedPackage() if the exception is genuinely acceptable. Re-validate your rules whenever you add dependencies, since tuning is housekeeping the tool cannot infer on its own.
- What are the alternatives to lendable/composer-license-checker?
- Alternatives include roave/security-advisories for vulnerability advisories and Composer's own composer licenses command for a manual report. Some teams write a small script around installed.json, but that tends to be less configurable than a rules-based checker with an allowlist. If your project is stuck below PHP 8.4, an older pinned release or a fork may be the practical route.
- Is upgrading to version 1.4.1 a breaking change for existing setups?
- No. 1.4.1 is a dependency-constraint patch that only widens the PHP upper bound to admit PHP 8.6; rules, output formats, and the public API are unchanged. Running composer update lendable/composer-license-checker is enough, and projects already on 1.4.0 need no code changes. Teams using ^1.4 absorb this and future PHP-version patches automatically, while teams needing audit reproducibility may prefer to pin the exact version.
Weaver
How can I help you explore Laravel packages today?