[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.3
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  needs-patch       |     Focuses:
------------------------------+---------------------

Comment (by ayeshrajans):

 Thanks for the ping @johnbillion. I had commented on other Trac issues as
 well, and I still think it's a good idea to simplify the logic in the
 `travis.yml` and not install PHPUnit globally.

 Removal of `composer.lock` file is a big step, and we should evaluate the
 pros and cons.

 **Reproducible builds**

 One of the major reasons to have a `composer.lock` in the first place is
 to make sure we get the exact same build in two `composer install` calls.
 Drupal and Joomla, both similar software as us and adopted Composer
 throughout the software before us, still keep their lock files in the
 repo.

 With the proposal to use composer to install other dependencies such as
 `sodium_compat`, I think it's important to lock down the non-dev
 dependencies to a specific commit hash and review dependency updates one
 by one. This adds some friction, but it's worth it for a software that
 powers 30% of the web :)

 Projects such as WordPlate encourage the use of Composer more and more,
 and I think as the WordPress Core, we should follow what the rest of the
 industry/community does.

 **Dev-dependencies**

 Although I suggest that we lock non-dev dependencies with a lock files,
 dev dependencies are a different story though.

 Our major dependency that we cannot lock down is PHPUnit. The current
 approach to install a different version globally isn't an elegant
 solution, but I understand why that workaround is there.

 As a first step, perhaps we can use a `composer require
 phpunit/phpunit:^4.0|6.0|^7.0` in the `travus.yml` file, and let composer
 pick the appropriate phpunit version depending on the platform.

 **npm package lock files**
 In the repo, we have the `package-lock.json` file present. I think we
 should be consistent in regards to PHP and JS dependencies.

 --

 Bottom line is that, I think we should keep the `composer.lock` file
 considering the tendency of us using composer dependencies in WordPress
 such as `sodium_compat`, polyfills, etc. It's considered a good practice
 to use lock files in major software, and I think we should follow suit.

 Our current phpunit installation approach could use some improvements such
 as the use if a single `composer require phpunit/phpunit:^x|^y|^z` command
 and remove the if/else blocks in the `travis.yml` file, and also not
 assume the global installation of dependencies.

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