composer install changes symfony.lock on deploy without vendor directory

[lostfocus]

We've noticed that a deployment process from scratch (i.e. without a vendor directory) with composer install adds new data to our symfony.lock. I was under the impression that lock-files (composer.lock and symfony.lock) were regarded as read-only during a composer install - is the fact that the symfony.lock is being changed a bug or a feature? And if the latter, where would I find documentation for that behaviour?

[nicolas-grekas]

I don't reproduce with a new project. Could you provide step-by-step instructions to see this behavior?

[lostfocus]

I can't really reproduce it with a new project, either and I can't share the composer.json of our internal tools, so I'm not too sure how to answer. We had a symfony.lock with the following package missing:

"laminas/laminas-diagnostics": {
     "version": "1.6.0"
},

(It was obviously missing, when we did a local composer update it added the entry.)

When we ran a composer install in a project directory which already had a vendors directory, it noticed that nothing had to be changed, so nothing happened.
But when ran composer install on a new vm, where composer had to download all the packages, we've seen that composer and/or flex had noticed that this package was required by the composer.json/composer.lock but wasn't present in the symfony.lock and added the entry.

[lostfocus]

Okay, I just had another example:
the local dev environment is PHP 7.3, the staging server is PHP 7.4.

After a composer install on the staging server, the symfony.lock changed:

     "php": {
-        "version": "7.3"
+        "version": "7.4"
     },

(And yes, I know the local environment should have the same PHP version as the staging server.)

[lostfocus]

Okay, this keeps happening. Today:

+    "laminas/laminas-code": {
+        "version": "3.4.1"
+    },
+    "laminas/laminas-eventmanager": {
+        "version": "3.3.0"
+    },

Is it to be expected that the symfony.lock changes with a composer install ?

[stof]

if you did not disabled plugins during the composer update, the list of applied recipes should not change in a composer install as it should already be uptodate.

[lostfocus]

Well, as far as I understand it, the symfony.lock should never change on a composer install - more often than not I've run into automated deployment pipelnes that are basically git pull && composer install - which breaks on the second run, when the composer install has changed the file on the server and there's a conflict with the upstream branch. (Hence why the composer.lock doesn't change, even if it is out of sync with the composer.json - it just gives a warning message.)

[andryska]

We're having the same issue.

When deploying a fresh installation, a composer install will update all symfony recipes, which changes a bunch of files.

@fabpot mentioned here that symfony.lock must exist in the repo. Ours does exist, with correct read permissions and all, but recipes are still updated.

@lostfocus have you found a solution?

[lostfocus]

@andryska on the projects where it is a problem we just git reset just before the pull, which is obviously pretty dirty. I do have a checkout of the flex repo here to try to find, fix and pull-request the bug myself but I haven't found the time so far to get myself up to speed on how the whole composer/flex/… ecosystem works internally.

[lostfocus]

Steps to reproduce

1. Start in an empty directory
2. composer require symfony/flex
3. composer require monolog/monolog

The symfony.lock should now look something like this:

{
    "monolog/monolog": {
        "version": "2.2.0"
    },
    "psr/log": {
        "version": "1.1.3"
    },
    "symfony/flex": {
        "version": "1.0",
        "recipe": {
            "repo": "github.com/symfony/recipes",
            "branch": "master",
            "version": "1.0",
            "ref": "c0eeb50665f0f77226616b6038a9b06c03752d8e"
        },
        "files": [
            ".env"
        ]
    }
}

4. now delete the lines that require monolog. (This is just an example to show a disparity between the lock file and the composer.json) The symfony.lock should now look something like this:

{
    "psr/log": {
        "version": "1.1.3"
    },
    "symfony/flex": {
        "version": "1.0",
        "recipe": {
            "repo": "github.com/symfony/recipes",
            "branch": "master",
            "version": "1.0",
            "ref": "c0eeb50665f0f77226616b6038a9b06c03752d8e"
        },
        "files": [
            ".env"
        ]
    }
}

5. run composer install - nothing should change
6. delete the vendor/monolog directory
7. run composer install - monolog will appear in the symfony.lock file again.

We do have the code that writes the lock file here: https://github.com/symfony/flex/blob/main/src/Flex.php#L578 - and it seems to be pretty deliberate. So now I'm once again wondering if maybe this is the expected behaviour?

[maxhelias]

@lostfocus just don't remove or touch the symfony.lock, versioned it as it is generated even if you delete the imported files.
It's easier for you to see if there's an update on the recipe and if you change your mind about installing it.

[lostfocus]

That was just for demonstration purposes.
My real issue is with the fact that the symfony.lock changes when composer install runs - which is a different behaviour than what happens with the composer.lock: when the composer.lock isn't up to date, I get a notice on a composer install call but it is not being changed while the symfony.lock changes. So my question is basically: is that expected behaviour? Is that something that is documented somewhere? I'll gladly do a pull request on the code or on the documentation, but I need to know what the expectation is.

[hanoii]

I am also experiencing a change on symfony lock, in my case is just adding a php version:

diff --git a/symfony.lock b/symfony.lock
index 33632bb..64d7aad 100644
--- a/symfony.lock
+++ b/symfony.lock
@@ -14,6 +14,9 @@
     "doctrine/lexer": {
         "version": "1.2.1"
     },
+    "php": {
+        "version": "7.2"
+    },
     "psr/cache": {
         "version": "1.0.1"
     },