Enhancement: Also validate if lock file is up to date

[localheinz]

This PR

• adds validation of whether composer.lock is up to date (if it exists), emits an error and exits with non-zero if it's not
• adds a --no-lock option which will emit a warning instead
• updates the docs

💁 Useful if you want to break the build because someone modified composer.json without updating composer.lock.

Example

Fiddle with composer.json in this repository, for example, change

{
    "autoload": {
        "psr-0": { "Composer": "src/" }
    }
}

to

{
    "autoload": {
        "psr-0": { "Composer": "src" }
    }
}

Before

$ ./bin/composer validate
./composer.json is valid

$ echo $?
0

After

$  ./bin/composer validate
./composer.json is valid
The lock file is not up to date with the latest changes in composer.json.

$ echo $?
1

After (with --no-lock option)

$  ./bin/composer validate
./composer.json is valid
The lock file is not up to date with the latest changes in composer.json.

$ echo $?
0

[localheinz]

@Seldaek

Not sure, would you like me to provide tests for this one?

[alcohol]

I'm not sure if it makes more sense to move this to a command by itself, or keep it as an option/flag just for install. What if you want your build process to check first, and do a composer update --lock if it isn't up to date (because, reasons)? A command to check/validate the lockfile could also simply be relied on by exit code, and possibly provide some feedback if it is not in sync.

[localheinz]

@alcohol

I'm totally open for suggestions! Do you have anything in mind that would make sense?

Maybe a VerifyCommand, resulting in

$ composer verify

or (to leave space for other things which would be useful to verify)

$ composer verify --lock

[alcohol]

The first example is too ambiguous, verify doesn't really describe what it does. I would sooner go for something like verify-lock then.

verify --lock looks ok too. Maybe you could also add a --json while you are at it then? It's pretty easy to validate the json schema. See #4217 for some inspiration.

And in the latter scenario, verify would just run all available checks.

[hkdobrev]

It's pretty easy to validate the json schema. See #4217 for some inspiration.

There's the composer validate command which validates composer.json against the JSON config schema.

[alcohol]

Ah right I forgot about that. Maybe add the --lock flag to that command?

[localheinz]

@alcohol @hkdobrev

Sounds great! Just give me a moment, I'm on the road, traveling.

[localheinz]

@alcohol @hkdobrev

Do you want to take a look?

[alcohol]

Looks good, but I have one concern that maybe @Seldaek might be able to offer some feedback on.

Should the lock file be checked by default as well? Then the option would become --no-check-lock (to skip it instead) which would be more in line with the other options.

[hkdobrev]

👍 I also support @alcohol's idea about --no-check-lock.

You should also update CLI docs and CLI command descriptions.

[localheinz]

@alcohol @hkdobrev

This is the route I was going down as well, but then figured it would break people's builds if they were using it already, what do you think?

[hkdobrev]

it would break people's builds if they were using it already

I think this is a good thing in this case. And Composer is still in alpha so going for consistency rather than BC is better. Also I think this is rarely used at the moment.

[localheinz]

@alcohol @hkdobrev

See #4230.

[localheinz]

@alcohol @hkdobrev

Also see #4230.

[alcohol]

@localheinz: You need to update it, @naderman introduced a merge conflict.

[localheinz]

@alcohol

Done!

[hkdobrev]

The composer validate command no longer validates composer.json only.

[localheinz]

@hkdobrev

Updated!

@alcohol @hkdobrev

What do you think, should this also work when specifying the file argument, that is, attempt to validate a lock file in the same directory as where the specified file has been found?

[alcohol]

Yeah that probably makes sense. If they just want to validate a json schema they can skip the lock check. Otherwise, check for a lock file in the same directory.

[localheinz]

@alcohol

Amended the PR, please have a look!

[alcohol]

Looks good to me.

/cc @Seldaek do you feel this might be too much of a BC change or acceptable?

[Seldaek]

Looks good to me, thanks! I doubt it will create issues but perhaps more people use this in build systems than I imagine.

[localheinz]

@alcohol @hkdobrev @Seldaek

Thank you for reviewing and merging, I appreciate it!