Problem/Motivation
We've got something wrong in the composer.json / composer.lock file in 8.1.x
Running composer install on 8.2.x
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.
Nothing to install or update
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
> Drupal\Core\Composer\Composer::ensureHtaccess
Running composer install on 8.0.x and 8.1.x
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
> Drupal\Core\Composer\Composer::ensureHtaccess
Proposed resolution
Fix it so warning does not appear.
Remaining tasks
User interface changes
None
API changes
None
Data model changes
None
Comments
Comment #2
alexpottThis is due to #2697637: Update composer.json to have correct version numbers - now composer.lock has to be managed different for each branch because the composer .json has a different hash.
Patch attached fixes the hash. This is going to be tricky to manage when two branches can have composer changes :(
Comment #3
alexpottThis must be testable...
Comment #4
alexpottYep this is testable - so at least we won't miss this in the future.
Comment #6
webflo commentedLooks good to me. Composer locker uses a slightly different logic but the test is good enough for our use case.
Comment #7
alexpott@webflo yep - I looked at the Composer locker but I didn't want to duplicate the logic in ::getContentHash() - because then we'd have to maintain a copy of that method.
Comment #9
alexpottLol so #2712643: Update behat/* to 1.7.1 and fabpot/goutte to 3.1.2 fixed this because it re-generated composer.lock
Given how easy this occurs I think we should add the test to 8.1.x and 8.2.x.
Comment #12
catchCommitted f926544 and pushed to 8.1.x. Thanks!
The test will make sure that issue doesn't regress this again when we cherry-pick to 8.1.x - can see if it fails the new test or not now.