First, I want to clarify that you should definitely commit composer.lock in your Laravel application repos.
It ensures everyone on the team has the exact same dependency versions, and your production deploy matches what you tested locally.
But packages are different.
When someone installs your package via Composer, your package's composer.lock is completely ignored.
Composer only looks at the lock file in the root application.
So committing it to your package repo has zero effect on anyone using your package.
Beyond being unnecessary, it can actually cause problems.
A package is typically designed to work across a range of PHP and Laravel versions.
Your composer.json might say "php": "^8.1" and "laravel/framework": "^11.0|^12.0".
But a lock file bakes in specific dependency versions.
For PHP, it's not the version itself that gets locked, but the packages Composer resolves may differ depending on whether you ran composer install on PHP 8.4 versus PHP 8.1.
This becomes especially problematic when you have a CI pipeline.
You want to test your package against PHP 8.1, 8.2, 8.3, and 8.4.
You want to test against Laravel 11 and Laravel 12.
But if you have a lock file, you'd need to delete it or run composer update in each matrix job to actually test those combinations.
So just don't commit it in the first place.
Add composer.lock to your package's .gitignore and let Composer resolve fresh dependencies based on your version constraints.
Here to help,
Joel
P.S. Your package should have tests though. Would you like help learning how to write effective tests? Check out our Laravel testing workshop.
