[wp-trac] [WordPress Trac] #47381: Remove the Composer lock file from version control

[WordPress Trac]

#47381: Remove the Composer lock file from version control
------------------------------+-------------------------------
 Reporter:  johnbillion       |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  5.8
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  needs-patch       |     Focuses:  coding-standards
------------------------------+-------------------------------
Changes (by jrf):

 * focuses:   => coding-standards
 * milestone:  Future Release => 5.8


Comment:

 I'd very much like to revive this ticket as the existence of the committed
 `composer.lock` file is - as @johnbillion states quite eloquently above -
 a blocker for easily testing cross-version PHP.

 == Reason to have a committed `composer.lock` file

 Let's look at the (valid) reasons for projects to have a committed
 `composer.lock` file:

 1. Runtime dependencies - i.e. things in `require` - which need to be
 locked to a specific version with which the software has been tested.

 This reason does **NOT** apply to WordPress.
 Yes, WordPress has runtime dependencies like Sodium Compat, PHPMailer,
 Requests and more. However, 1) those are not (currently) managed via
 Composer and 2) if that would change in the future, those could be locked
 at a fixed version constraint instead of allowing for a version range.

 2. Contributors only need to worry about their contribution working with
 one particular set of dependencies.

 This reason again does **NOT** apply to WordPress as all WordPress code
 needs to work cross-version, so only, for instance running the tests
 against PHP 7.4 using PHPUnit 7 and sending in a pull request/patch and
 expecting it to be accepted, even though the tests don't pass on other PHP
 versions, is not acceptable.

 So, having said that, I don't see a valid reason for having a committed
 `composer.lock` file.

 Consistency with the NPM side of the project, to me, is not an argument as
 NPM and Composer/PHP are very different beasts and the use of a `lock`
 file for either should be evaluated on their own merits in each situation.

 == Reasons to remove it the committed `composer.lock` file

 1. Make it easier for contributors to test against multiple different PHP
 versions locally.
 2. Make it easier to reproduce the builds run on GH Actions locally
 without having to check in the GH Actions script what hacks are needed to
 get the builds to run.

 == Other considerations

 You may say, but what about managing things like WordPressCS ? We don't
 want builds to start failing randomly because WPCS released a new
 version....
 And yes, you are right to bring that up. Tools like WPCS should be fixed
 to a specific version when we remove the `composer.lock` file to prevent
 random build failures on a new release.
 We should probably also add a fixed dependency to a specific
 PHP_CodeSniffer version as otherwise - with WPCS allowing for a wider
 range of PHPCS versions -, a new PHPCS release may have a similar effect.

 In other words, that is something which can be managed via the
 `composer.json` file instead of via a `lock` file and tickets should be
 opened on a new release of those type of dependencies to do a managed
 update.

 == Moving forward

 All in all, I'm very much in favour of removing the `composer.lock` file.

 To do this, as far as I can see, a patch would be needed which covers the
 following:
 - [ ] Remove the `composer.lock` file.
 - [ ] Add the `composer.lock` file to `.gitignore` and `svn:ignore`
 - [ ] Fix the version constraints for a subset of the `dev` dependencies -
 in particularly WPCS and PHPCS - in the `composer.json`
 - [ ] Remove all "hacks" currently in place in the GH Actions workflow
 scripts to allow for running things cross-versions.
 - [ ] Make sure there is still a passing build after that 😁

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47381#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform