composer: Lock file not updated when only repo pathes change
When the URL of a repository changes (but not the commit/file sha) the lock file doesn’t get updated when running composer update
.
This leads to failing installs on systems that only install from the lock file.
Reproduce:
echo "1" > /tmp/foo.php
zip /tmp/foo.zip /tmp/foo.php
cp /tmp/foo.zip /tmp/bar.zip
mkdir composer-1620 && cd composer-1620
vi composer.json
using this composer.json file:
{
"repositories": [
{
"type": "package",
"package": {
"name": "foo/bar",
"version": "1.0.0",
"dist": {
"url": "/tmp/foo.zip",
"type": "zip"
}
}
}
],
"require": {
"foo/bar": "*"
}
}
Running composer install
results in this lock
file:
{
"hash": "ffd99334693f19c1133026fc14a8f303",
"packages": [
{
"name": "foo/bar",
"version": "1.0.0",
"dist": {
"type": "zip",
"url": "/tmp/foo.zip",
"reference": null,
"shasum": null
},
"type": "library"
}
],
"packages-dev": null,
"aliases": [
],
"minimum-stability": "stable",
"stability-flags": [
]
}
now going back to the composer json changing the "url"
from foo
to bar
field to:
"dist": {
"url": "/tmp/bar.zip",
"type": "zip"
}
and running composer update
will not change the lockfile.
Which means removing the old “repo” and reinstalling fill fail
rm -rf /tmp/foo.zip ./vendor ~/.composer/cache
composer install
now results in:
Loading composer repositories with package information
Installing dependencies from lock file
- Installing foo/bar (1.0.0)
Downloading: 100%
[Composer\Downloader\TransportException]
The "/tmp/foo.zip" file could not be downloaded: failed to open stream: No such file or directory
Basic gist:
Running
composer update
rm -rf ./vendor/ ~/.composer/cache
composer install
should not result in the update working but reinstalling failing.
Expected:
Lock file gets updated and the url
now reads /tmp/bar.zip
.
Actual
Lock file stays the same.
Workaround
Deleting the lock file and running composer install
produces the correct lock file but it ofc changes all the other versions.
Editing the lock file manually (or removing that section and running update) works too.
Thank you!
About this issue
- Original URL
- State: closed
- Created 11 years ago
- Comments: 19 (11 by maintainers)
I ran into this same issues when updating repos to use Satis. It’s a “one-off” change so not great hardship, except the “one-off” change was repeated a few times while testing various scenarios.
I didn’t want to do a full composer update and test/integrate various unrelated dependencies, but this worked:
Only after this, the composer.lock was correctly updated to reflect the Satis location.
Thanks for the response.
I can see that this is annoying to fix and might create more hassle and maintenance than it’s worth for you.
Since this is something that happens on a regular basis for us (and always breaks installs for +20 people) I’ve just written a small script that resyncs the repo urls from the composer.json to the composer.lock file 😃
@edorian the issue is just that the package doesn’t get updated at all, so the new info you put in composer.json isn’t added to either the lock file or the installed repository (vendor/composer/installed.json). If you change the version that forces an update. I realize it’s a nasty edge case, but solving this would require real ugly hackery, so I prefer to keep this as a technical limitation of package repositories. To force an update you can rm vendor/foo/bar and run update, then it will reinstall the package and copy over the new info (it’s not just repo urls, it’s autoload config etc as well).