Composer.lock and plugin version control strategy

[TeemuSuoranta]

I noticed that composer.lock was recently automatically ignored from the version control https://github.com/Seravo/wordpress/commit/f954bdd4e6b3ed77568a65a808f9400ae6a4f8d0

I have read the commit notes and agree that the file has many issues as updates in production do not (to my knowledge) update composer.lock and packages in composer.json have no fixed version most of the time.

As a background we have usually added the WordPress.org plugins via composer and kept premium and custom plugins in version control. Now, when you add a new plugin via composer, there is pre-made git hook in production that also installs it if there is change in composer.lock. If this file is not in version control, this automation will not work (manual command needed in production).

As a developer I don't want to have this manual and easy to forget thing in the workflow which leaves (at least) two strategies:

1. Manually re-add the composer.lock to the version control and keep workflow the same.
2. Add all the plugins to the version control to minimize the need for composer.json in the first place. This will lead to more uncommited changes in production situations, but fix all issues with composer.lock. For this option, we'll need to change the default .gitignore for plugins each time.

What do you think? With this change there is a hole in the workflow when a new (WordPress.org) plugin is added to the site in local development that needs some kind of solution.

[samikeijonen]

We already re-added the composer.lock to the version control for reasons Teemu outlined.

To sum it up. I'd prefer project dependencies and version numbers be consistent and same across production, all developers on local, and CI servers automatically.

My suggestion would be adding composer.lock back in.

[ottok]

Thanks for the suggestions. The development->production git push + git hook syncing would benefit from composer.lock.

There is no way to guarantee that version numbers be consistent and same across production and development. Any user can at any time install or upgrade a plugin in wp-admin or via wp-ci and the composer.json or composer.lock files would not get any updates. WordPress does not offer the same developer experience for dependency management as e.g. NodeJS with package.json offers.

In local one can however run 'wp-pull-production-plugins' to sync from production->development.

[samikeijonen]

There is no way to guarantee that version numbers be consistent and same across production and development. Any user can at any time install or upgrade a plugin in wp-admin or via wp-ci and the composer.json or composer.lock files would not get any updates.

True but keeping composer.lock file helps a little as a compromise. And helps with CI pipelines also.

And surely not any user, some roles for sure :)

[spktklr]

+1

[GeriYatola]

+1 for reverting f954bdd4e6b3ed77568a65a808f9400ae6a4f8d0

We just ran into this issue ourselves, when pushing composer.json changes to a new staging remote. Since composer automatically generates composer.lock on the first run, it is used on subsequent runs as well. Mismatch between composer.json and composer.lock is detected, but no packages are installed.

remote: Seravo: composer.json was updated, installing...
remote: Installing dependencies from lock file
remote: Verifying lock file contents can be installed on current platform.
remote: Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`.
remote: Nothing to install, update or remove

We would also prefer committing composer.lock despite the possibility of plugin version drift mentioned in f954bdd4e6b3ed77568a65a808f9400ae6a4f8d0 and here by @ottok .

Preventing version drift should be managed by team (in development) and permissions (preventing plugin updates in wp-admin) or communication (agreeing that updates are never done through wp-admin).

Alternatively https://github.com/Seravo/wordpress/blob/master/scripts/git-hooks/post-receive#L72 should delete composer.lock if it exists to allow composer install --no-dev to install updated dependencies.