Symfony.lock changes during composer install

[stlrnz]

I discovered a strange behaviour when deploying Symfony Flex applications on Windows using Git and Composer. Somehow the line endings in symfony.lock are changing during composer install. Maybe someone can give me a hint what I'm doing wrong or what I can do better.

The Environment:

• Windows based development machine
• Windows based production sever
• Git configured with core.autocrlf=true on both machines

Steps to reproduce:

1. Create a new project on dev
   composer create-project symfony/skeleton demo
symfony.lock is created using LF charater as line endings ✔️

2. Add everything to Git
   cd demo
git init
git add -A

3. A warning is displayed but symfony.lock still has LF line endings in working copy ✔️

warning: LF will be replaced by CRLF in symfony.lock.
The file will have its original line endings in your working directory.

4. Commit & Push
   git commit -m "init"
git remote add origin https://...
git push -u origin master

5. Clone project on prod machine
   git clone https://... demo
symfony.lock now has CRLF line endings (because of core.autocrlf=true) ✔️

6. Check status
   cd demo
git status

On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

7. Install project
   composer install
symfony.lock now has LF line endings ❓

8. check status again
   git status

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)

    modified:   symfony.lock

no changes added to commit (use "git add" and/or "git commit -a")

So my question is why is symfony.lock updated during composer install? Is that an expected behaviour? I thougth it should be read-only during install just like composer.lock?

Everytime I update my project on production I will have to revert the changes to symfony.lock before I can do a git pull. Thats not very intuitive.

[Kris2x]

I noticed the same problem. This is normal?

[Solthun]

Issue source is line endings in different OS, so run git config --global core.autocrlf false && git add --all (https://stackoverflow.com/a/49324186/2591726)

[stlrnz]

Im sure this is a proper workaround.
But the questions stays the same: Why is symfony.lock updated during composer install? I thought this should be a read only operation.

[fabpot]

symfony.lock must NOT be updated during composer install. If you have an "old" project, first upgrade to the latest version of Flex, and then run composer update first to update the symfony.lock file. Then, it should not update anymore on composer install. If it does, there is a bug somewhere.

[stlrnz]

Thank you for your feedback, @fabpot.
I've tested the scenario again. I set up a new project like described above using Flex 1.1.8.
The result is still the same: During composer install the symfony.lock file is generated again. The content stays the same but the line endings are changing to LF.

[stlrnz]

Nice Flex 1.2 update, @fabpot!
However, I've tested this issue again with a brand new project using flex 1.2.0. The behaviour ist still the same.
Any chance to solve this problem?

[nicolas-grekas]

Would you mind having a look? The code is also yours to debug ;)

[stlrnz]

Sure.
From what I found out, it's because Flex does the same on composer install like on composer update:

flex/src/Flex.php

Line 288 in 7f04fb5

$this->update($event);

On update all (new?) recipes are fetched. If there are no recipes (which is the case for composer install), the Lockfile will be written:

flex/src/Flex.php

Line 315 in 7f04fb5

$this->lock->write();

(Otherwise the Lockfile will be written, too. But that should never be the case on composer install.)

So the question is why is it needed to run Flex on composer install? Shouldn't all receipes be executed only during updating commands like composer require or composer update?
Is it only to create .env files? This could easily be separated.

[redusek]

How is this closed? It seems that composer install should not be attempting to update symfony.lock at all, but the solution is only to not update it unless recipes have changed? How is this acceptable? It shouldn't be updated even if recipes change. My expectation is that if it is not going to be able to install and use only what is in symfony.lock it should fail.

[kevinpapst]

With a bit of luck this is finally fixed by #794