Asset composer.lock is not valid

[drupol]

Hello,

Context: following our initial conversation at #767

Today I tried to use the composer.lock file published in the release asset for the next update of Psysh in Nix... and during the process, the validation of the composer.lock is failing, as seen in the log that I reproduced locally:

❯ cd /tmp
❯ git clone [email protected]:bobthecow/psysh.git
Cloning into 'psysh'...
remote: Enumerating objects: 16958, done.
remote: Counting objects: 100% (3660/3660), done.
remote: Compressing objects: 100% (1120/1120), done.
remote: Total 16958 (delta 2732), reused 3322 (delta 2503), pack-reused 13298
Receiving objects: 100% (16958/16958), 3.95 MiB | 3.65 MiB/s, done.
Resolving deltas: 100% (11564/11564), done.
❯ cd psysh/
❯ git co v0.12.3
Note: switching to 'v0.12.3'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at b6b6cce7 Merge branch 'release/0.12.3'
❯ wget https://github.com/bobthecow/psysh/releases/download/v0.12.3/composer-v0.12.3.lock
❯ composer validate
./composer.json is valid but your composer.lock has some errors
# Lock file errors
- The lock file is not up to date with the latest changes in composer.json, it is recommended that you run `composer update` or `composer update <package name>`.
~/C/t/psysh > HEAD > [email protected] > php ✘ 

Would it be possible to make sure the composer.lock in valid when running composer validate ?

If this seems inappropriate, perhaps publishing the composer.json as well might be an option?

Thanks!

[bobthecow]

Oh, yeah, that won't work.

The composer.json is updated during the phar build process. Because it has phar-specific dependencies, it's never committed to the repo as it's not the "real" package info.

You could apply those package changes yourself before running composer validate, which works but feels weird :-/