-
-
Notifications
You must be signed in to change notification settings - Fork 196
Description
Initially, the symfony.lock
file stored just the version number of a recipe or package. At some point, the symfony.lock
format was expanded to store additional information, such as the files that are maintained by the recipe.
When composer recipes:install
(AKA sync-recipes
or fix-recipes
) is run, it conveniently adds to symfony.lock
information on packages that are already installed. However, it appears the synchronization behavior was not updated to store the additional information when it is missing.
So, for example, if you installed a recipe for version 1.0 of the foo/bar package prior to the expansion of the symfony.lock
format, you might have an entry that looks like this:
"foo/bar": {
"version": "v1.0.0"
},
If you were to install that same recipe now, you might get an entry that looks like this:
"foo/bar": {
"version": "1.0",
"recipe": {
"repo": "github.com/symfony/recipes",
"branch": "master",
"version": "1.0",
"ref": "c0eeb50665f0f77226616b6038a9b06c03752d8e"
},
"files": [
"config/packages/bar.yaml"
]
},
I would expect that running composer recipes:install
on the older installation would make it update symfony.lock
to look like the newer installation, but it does not.
Additionally (and this might be a separate issue), if a package is installed that does not have a recipe associated with it, an entry is added to the symfony.lock
file that just stores the version of the package that was installed. However, if that package is later updated (or removed!), the symfony.lock
file is not updated accordingly.
This means that removing the symfony.lock
file and running composer recipes:install
again does not guarantee that the new file that is created will match the old file, even if all the recipes and their code is the same.