I found the composer.json & composer.lock(php) has conflict section (not to be confused with merge conflict ). The other similar files like package.json/yarn.json (nodejs) or Pipfile (python) and the corresponding lock files package-lock.json/yarn.lock or Pipfile.lock, do not have such format even though all these lock files serve the same purpose (lock the dependence to the exact version) and implement in the similar way (at least looking from the surface)
So what is usage of it and what should I do with it ? I read the composer document https://getcomposer.org/doc/04-schema.md#conflict but I still feel confused, e.g.
Map of packages that conflict with this version of this package. They will not be allowed to be installed together with your package.
For example after running composer install I have a composer.lock saying
{
"name": "symfony/http-kernel",
"version": "v4.4.20",
...
"conflict": {
"symfony/browser-kit": "<4.3",
"symfony/config": "<3.4",
"symfony/console": ">=5",
"symfony/dependency-injection": "<4.3",
"symfony/translation": "<4.2",
"twig/twig": "<1.43|<2.13,>=2"
},
...
It is easy to guess "symfony/console" 5.0 is conflicted with "symfony/http-kernel" 4.4.20 so symfony/console 5.0 will not be installed.
Do I need to do anything with the conflict ? So far I feel like that as a package user (not the package developer) those info is just a FYI and I don't need to do anything. But then why bother to list them for me ? After all package.json and Pipefile don't have such information and I don't find the problem without it.
--- update ---
From the answer I got I realize I need to emphasize this: I understand composer.lock is for composer so I don't need to worry about it.
What I don't understand is the purpose putting it in composer.json, this file is for human users. So if it has a conflict section what should I do about it?
I want to know a practical use case of "conflict" section in my composer.json if I am not a package developer but a package user.
When building an application, you are free to choose your dependencies way better than when you are building a reusable library like symfony/http-kernel which you've mentioned in your question.
Putting any other package constraint in the conflict section of such a package means: if you want to install the package in the current version, no other package version must be installed that is listed in the conflict section. From your example: symfony/http-kernel in v4.4.20 must not be installed if symfony/browser-kit is installed in any version <4.3.
In your own application, you have more freedom to use stricter constraints for the packages you use. You could require all packages with pretty strict version numbers, but this makes updates less comfortable. For example, this is a part of the require section in one of my current projects:
"doctrine/annotations": "^1.0",
"doctrine/doctrine-bundle": "^2.2",
"doctrine/doctrine-migrations-bundle": "^3.0",
"doctrine/orm": "^2.7",
"easycorp/easyadmin-bundle": "^3.1",
"exercise/htmlpurifier-bundle": "^3.1",
"knplabs/knp-snappy-bundle": "^1.8",
"league/csv": "^9.6",
"lexik/jwt-authentication-bundle": "^2.10",
"nelmio/cors-bundle": "^2.1",
All these packages might install tons of other dependencies which I cannot control. But if I know that any version of the other dependencies causes trouble, I can list them in the conflict section of my application such that this version is not installed.
For example, in the past I've needed that for an update of doctrine/migrations where the configuration has changed. I wanted to be able to update all packages except this one, because I didn't want to bother with the configuration changes I had to apply to my application for a while.