Coding Standards

WordPress coding standards are still the baseline across Jetpack, but we also have some notable additions covered below.

PHP

We use PHP Code Sniffer for enforcing Jetpack PHP Coding Standards. It will be installed for you as a monorepo dependency.

• When working on a module, make sure it’s declared in the inline doc – like this. The same applies for filters and actions, as shown here.
• Sanitize URLs, attributes, everything. WordPress.com VIP has this nice article about the topic.
• Create unit tests if you can (here are the Jetpack plugin tests for reference). In case you need it, take a look at this tutorial.

JavaScript

We have a preferred stack for JavaScript projects across Jetpack, built around Webpack, Babel, Gutenberg and React, in order to minimize friction between different packages in the monorepo as well as the wider WordPress ecosystem.

The preferred configuration and reliance on WordPress core libraries as much as possible is strongly recommended, but it’s not enforced. Teams and contributors are free to choose solutions and bring in dependencies that work best according to their specific needs. We only ask you to weigh the tradeoffs thoroughly, including support for the new libraries, with a clear goal in mind.

Browsers

Jetpack follows WordPress Core browser support guidelines and we rely on browserlist-config for an up-to-date reference in our tooling.

General Dependencies

When it comes to dependencies in general, particularly large ones, it’s preferred to choose options already in use inside the Jetpack Monorepo.

• If you need a different version of a library already in use, consider upgrading it across all projects that rely on it.
• If the required library is a superior option to another library already in use elsewhere, list out the pros and cons and consider starting a project to migrate existing use cases to the new library.
• When consuming our own projects/js-packages within the Monorepo, the package should provide jetpack:src entries in .exports in package.json to avoid having to build before eslint can run. Do not use .scripts.prepare or the like to try to compile on installation, as that slows down and complicates installation for everyone even if they’re not using that package.

Project based language and tool versions

It’s possible for individual projects or types of projects to have specific requirements that further extend the base requirements. For example Jetpack CRM’s readme states a higher minimum PHP version than what is required by default.