Skip to content

Coding Standards Reboot
Compare
Choose a tag to compare
@gregrickaby gregrickaby released this 20 Apr 11:58
· 584 commits to main since this release
2.1
90d2bb6

This release includes a complete and total overhaul of WDS Coding Standards. In short, we're just using WordPress Coding Standards.

History

Many years ago, WDS created its own PHP standards on top of WordPress PHP Standards. At that time Gutenberg wasn't even on the radar. We also created our own standards (and ruleset files) for Sass and JavaScript and included them in wd_s. Eventually, we even created Github repos, NPM packages, and even our own "WDS Scripts" package for compiling assets.

Since Gutenberg was released, WordPress now maintains ruleset files in both WordPress Develop and the Gutenberg repos for languages like Sass, JavaScript, and more. There's also @wordpress/scripts for compiling styles, scripts, and assets.

The Problem

Maintaining our own standards and scripts was time consuming and using coding standards as packages sometimes caused issues. What happens if a Project Lead updated the project dependencies? Code editors are barking at Engineers about the entire codebase! Ugh. Projects themselves couldn't easily adjust standards to meet the project's needs either, and finally, the endless debates about them were exhausting.

There is no point in maintaining our own standards, scripts and NPM packages... let's just adopt what WordPress is doing.

The Solution

  • Use the exact ruleset files and configs from WordPress
  • Sprinkle in a handful of WDS preferences (like array short syntax and Tailwind support)
  • Use @wordpress/scripts (as natively as possible) for compiling assets
  • Leverage linting via Webpack to provide real-time feedback
  • Enforce via the pre-commit hook in Git
  • Assert using Buddy at the PR level

The Benefits

  • By adopting native @wordpress/scripts and deferring minifying to production builds only, npm run watch compilation times were reduced from ~6-8 seconds down to ~2. 💪🏻 😮
  • Prettier and PHPCBF support 🥳
  • Hopefully with the pre-commit hook, we'll have less back-and-forth during a Pull Request. Engineers will be forced to check-in properly formatted code. This is good for the bottom line! 💰
  • The standards will "live on" for the entire life of the theme 😄
  • Project Leads can easily adjust standards from project-to-project 😏
  • No more NPM packages, Github repos, or Scripts to maintain 🎈
  • WP CLI is included as a Composer dependency now 🚄

Usage

  • Clone the main branch of wd_s
  • Open wd_s in your code editor as the root
  • Type npm i --legacy-peer-deps
  • Type npm run watch to kick-off the dev server and Browsersync
  • Your code editor and linting plugins should pick up on the rulesets and configs automatically
  • Prettier and PHPCBF (if you have those plugins installed in your IDE) should auto-format your code
  • Webpack is watching any warnings or errors too, and will report them in the CLI
  • Finally, Lefthook will prevent commits until the codebase is "clean"

Bypass Pre-Commit Hook

Not everyone want's to be stopped and forced to format their code prior to a commit. Especially if it's early in your feature, and you're working in a dirty branch prior to opening a pull request.

You can bypass the pre-commit hook by using the --no-verify flag.

git commit -m "fixed the thing" --no-verify

Note: Buddy will still run assertions against your PR, so don't forget to clean things up before opening it!

Props

Thanks to @aubreypwd @jrfoell @richaber @salcode and @coreymcollins for all their testing and support.

Assets 2
Loading