- What does metasyntactical/composer-plugin-license-check actually do?
- It is a Composer plugin that inspects the licenses of your installed dependencies and compares them against a set of allow and deny rules you define. If a package falls outside those rules, the check flags it so you can deal with the problem before it ships. Because it hooks into Composer rather than your application code, it works the same way in a Laravel app as in any other PHP project.
- How do I install the license check plugin in a Laravel project?
- Install it with Composer, typically as a dev dependency so it does not ship to production: composer require --dev metasyntactical/composer-plugin-license-check. On Composer 2.2 and newer you will likely be asked to permit the plugin, which you can do by adding it to the allow-plugins section of your composer.json. After that, the plugin runs as part of your normal Composer workflow.
- How do I configure which licenses are allowed or denied?
- You express your policy as allow and deny rules in the plugin's configuration, usually inside composer.json under the extra section. Licenses are matched by their SPDX-style identifiers, such as MIT, Apache-2.0, or GPL-3.0-only, rather than by package name. Check the package README for the exact configuration key names and rule syntax before rolling it out across a team.
- Does this plugin support Laravel 10 and Laravel 11?
- The plugin is a Composer-level tool and is not tied to a specific Laravel version, so it works with Laravel 10, 11, and older releases as long as your Composer version is supported. It also works in non-Laravel PHP projects, which makes it easy to standardise the same policy across services. If you hit an incompatibility, it will usually be a Composer version issue rather than a Laravel one.
- When does the license check run during install or update?
- Because it is a Composer plugin, it hooks into Composer's package events, so the check runs as part of composer install and composer update rather than as a separate command you have to remember. That means a problematic dependency is caught at the moment it enters your dependency tree. You can also run it deliberately as part of a build step if you prefer a fail-fast gate.
- Can I use it in a CI pipeline to block non-compliant dependencies?
- Yes, running composer install in CI is enough to trigger the check, and a non-zero exit will fail the build. This is a common pattern for teams that want license enforcement without relying on developers to run anything locally. Keep in mind the check only sees what Composer installs, so make sure CI installs from the lock file with the same configuration as local development.
- What happens when a dependency has a disallowed license?
- The plugin reports the offending package and its license, and the Composer run fails so the dependency cannot silently slip through. You then decide whether to replace the package, exempt it, or change your policy. Failing loudly is the point: it turns a legal review question into a build error you can act on immediately.
- Can I exempt specific packages from the license rules?
- Allow and deny rules are configurable, so you can carve out exceptions for packages you have already reviewed and cleared with legal. This is useful for a single transitive dependency that uses a license your policy otherwise forbids. Document any exemptions in the repository so the reasoning is not lost the next time someone reads the config.
- How does it handle packages with no license or multiple licenses?
- Composer exposes license metadata as declared by each package, and packages can list none at all or several at once. The plugin evaluates whatever is declared against your rules, so an unlicensed package or a dual-licensed one can behave differently from a clean single-license dependency. Test your rule set against your actual dependency tree, since unlicensed packages are exactly the ones worth catching early.
- Is this a replacement for a full dependency or legal audit?
- No. It is a lightweight guardrail that enforces the policy you define; it does not interpret license compatibility, obligation terms, or attribution requirements for you. Treat it as an automated first pass that stops obvious problems, alongside periodic manual review for anything legally sensitive. It is also worth pinning the plugin version and reviewing your rule set when dependencies change significantly.