Push your code. GitLab CI rejects it. Fix, push, wait, repeat. Three rounds later you've spent an hour of your day on a missing docblock and a trailing space.
Every one of those failures is catchable on your laptop in under a minute. Drupal.org's GitLab CI pipeline runs PHPCS, PHPStan, ESLint, Stylelint, and CSpell against your merge request, and there's no reason you can't run all five inside DDEV before you commit.
The reason most people don't is configuration. Five tools, five config files, each with Drupal-specific rulesets and exclusions you have to get right. So I built ddev-drupal-code-quality: one ddev add-on get, and you have working configs for all five.
We'll take an example project through the whole loop. Run the checks. Read the output and figure out which errors matter. Let PHP Code Beautifier fix the whitespace and formatting violations it can handle on its own. Set a PHPStan baseline so errors you inherited stop drowning out the ones you just wrote. Then work through what's left, one checker at a time.
You'll also see how to get this into your editor, so PHPCS complains while you're typing rather than ten minutes after you push, and when to reach for ddev-drupal-contrib instead: that's the one for standalone contrib modules and themes.
No prior experience with these tools required. The add-on handles the configuration, and I'll show you what to do when it breaks. Come with a red pipeline; leave with a green one.
Attendees will leave able to:
- Install ddev-drupal-code-quality and run PHPCS, PHPStan, ESLint, Stylelint, and CSpell locally against Drupal coding standards.
- Fix errors incrementally with autofixers and PHPStan baselines, instead of stopping feature work to clean an entire codebase.
- Wire the checks into their editor so failures surface at write time rather than in CI.