What is usage of "conflict" in composer.json and what should I do with it?

Question

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?

Answer 1

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.

Answer 2

"conflict": {
    "symfony/console": ">=5",

this means that for some reason your package can't work with symfony/console version 5 and higher, so it will keep it below 5.

E.g. you can exclude some package faulty version:

"conflict": {
    "foo/bar": "1.420.69",
} 

Answer 3

I know this is an old post, but thought I'd add a point to what's already been said:

You may still benefit from a conflict section in composer.json if you know any of your code conflicts with any packages. It could be any reason from both your code and the package trying to do similar jobs and stepping on each other's toes or simply that a package is badly written and breaks your code.

In that case, you can add a conflict section in your composer.json to tell composer to never download that package (or some releases of it).

This would be useful if you work with other developers and someone else might try to require that package, or if you worry that composer may try to install it as a dependency of yet another package e.g. X is the package you don't want, but another package Y depends on X and you don't know. Without the conflict section, composer would download package X without you even knowing/noticing.