Missing Dependencies and Open Source Contributions

Today I learned about weekly work journals and figured I would try to keep one myself since there is usually a lot of learning happening during the week and most of that knowledge is hidden in client projects and internal company chats.

Validate Dependencies

The staging site for one of the projects went down because of a missing PHP dependancy and it happened because of a merge conflict in composer.json which was resolved incorrectly. We decided to introduce mandatory pull requests for all code merged to staging and added composer validate to the Travis CI checks to ensure that composer-lock.json and composer.json are valid and in sync.

Contributing to WordPress Coding Standards

I decided to contribute to the WordPress Coding Standards project by cleaning up the composer.json file but it appears that the project doesn’t embrace Composer as the suggested “default” task runner so the suggested changes were not a good fit.

Composer appears to be the default method for adding the WordPress coding standard checks to all projects so I’m not sure why the installation instructions suggest cloning the project repository into a directory:

composer create-project wp-coding-standards/wpcs --no-dev

instead of adding it as a developer dependancy to a project:

composer require wp-coding-standards/wpcs --dev

Installing coding standards globally seems to be an anti-pattern and shouldn’t be suggested as the default.

UX of Code

Documentation and tooling is the UX of coding — it can either encourage usage and contributions or make it complicated and hard. Sane defaults and consistent tooling is a simple way to improve the developer experience.

Contributing to wp-dev-lib

wp-dev-lib is a set of bash scripts for adding coding standards and automated testing to primarily legacy WordPress theme and plugin projects since all of the checks run only for the new code by default.

In this pull request I restructured the codebase by moving all scripts into a dedicated directory and all sample configuration files into another. I also added a sample project to the repository which is used for automated testing during the Travis runs.

I also updated the usage instructions to suggest installing using Composer or npm instead of Git submodules, and using Composer/npm scripts for setting up the pre-commit hook.

Overall, this was a great and productive week. I’m a bit worried about doing so many different things in one week and would like to spend more time reading and learning instead of creating.

Leave a Reply