Active
Project:
Coder
Version:
9.x-dev
Component:
Code
Priority:
Normal
Category:
Plan
Assigned:
Unassigned
Reporter:
Created:
19 Apr 2026 at 11:20 UTC
Updated:
27 Sep 2026 at 10:21 UTC
Jump to comment: Most recent
Problem/Motivation
There is a super fast PHP formatter, linter and analyzer written in Rust: mago https://github.com/carthage-software/mago . A Drupal preset for formatting Drupal code has already been committed in Mago, yay!
The problem now is that Mago fmt does not support doc comments yet for example: https://github.com/carthage-software/mago/issues/906
So we cannot replace PHPCS with Mago, and probably not for a long time. It lacks some sniffs we have in Coder and might never implement them. What we can do is establish best practices how to run Mago and Coder/PHPCS together.
Proposed resolution
- Use mago fmt and PHPCS with Coder for everything that mago does not check yet
-
Define a new PHPCS Standard for that in Coder: DrupalMago
- It includes only sniffs that mago does not cover
- Add a new helper CLI command to generate a Mago config from a PHPCS config
-
Add a new helper CLI command that runs 4 parts:
- mago fmt
- mago lint
- mago analyze
- phpcs
- Add documentation about Drupal best practices what can be used from Mago
Remaining tasks
Discuss the best approaches and ideas how we can use Mago for Drupal, then implement helpers.
API changes
None.
Issue fork coder-3585617
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
amateescu commentedI like this plan a lot :) Also wanted to point out that I've created a ddev addon for mago: https://addons.ddev.com/addons/amateescu/ddev-mago
But maybe we should try to get it into ddev's web container directly...
Comment #3
amateescu commentedAnd custom rules might become a reality quite soon: https://github.com/carthage-software/mago/pull/1663
Comment #4
klausiI like that you can install Mago with composer, so DDEV does not have to do anything and you can run it the same way as PHPCS. https://mago.carthage.software/guide/installation#composer-php-project
Also happy to discuss Mago at Drupal Dev Days, I'm doing a session there https://devdays2026.drupal.org.gr/drupal-developer-days-athens-2026/sess...
Comment #5
johnatas commentedHi,
Thanks klausi for your session at Drupal Dev Days, it was really great.
Thanks amateescu for the ddev addon. On my side, I’m using GrumPHP to ensure code quality on my Drupal projects (and to run all my linters/analyzers/formatters in parallel).
There was already an issue opened to add Mago as a task in GrumPHP, and I’ve just opened a PR in case it might be of interest to some of you: https://github.com/phpro/grumphp/pull/1216
Comment #7
wim leersAnything I can do with adopting this early in Canvas that would help y’all here? 🤓
Canvas follows Drupal core’s coding standaards, disabled a dozen of the most boiler-plate-y rules, and adds a bunch of extra ones (including some custom rules). It also complies with PHPStan level 8. So I suspect it might be a helpful testing ground?
Comment #8
klausiHi, sorry this has stalled a bit.
What you can do in the meantime is running and documenting Mago with Drupal. Setup Mago for your project, check which issues the formatter, linter and analyzer finds on your code base. Then document which ones you don't like or don't want. Note that the formatter will interfere with PHPCS/Coder a bit, hence this issue so that you can run the Mago formatter for most coding standards and PHPCS for the rest it misses.
Also setting up Mago in Gitlab CI for a Drupal contrib project would be very interesting, so that a maintainer can opt into a Mago check on their project.
Comment #9
amateescu commentedMago 1.47 added support for extensions, and I started building a Drupal extension here: https://github.com/amateescu/mago-drupal
Today I finished the linter part, which can now be used to fully (well.. 99%) replace phpcs for Drupal projects, and started using it for Trash: https://www.drupal.org/project/trash/issues/3625072 . The code needed to integrate it with gitlab CI is quite minimal, as can be seen towards the bottom of that MR :)
The performance is amazing, 37x faster than phpcs on one CPU thread, and about 9x faster on my desktop with 24 threads.
The analyzer part is in progress, but replacing phpstan is a much bigger task so it'll take a bit more time. Unfortunately, the extension API does not support its formatter yet, so that one will have to wait as well.
I'm also trying to push a few improvements for the Drupal integration in Mago itself, and any help or voice for support would be awesome:
Comment #10
klausiHey nice work! Then I think this special issue for Coder is obsolete, I think it does not make sense to run both phpcs and mago in a project. People can just fully switch to mago for formatting and Coder is not relevant anymore for them.
Instead we should start documentation how to setup Mago for:
* a contrib module
* a client Drupal project
I will try to switch the Graphql module like you did for Trash module and then document the steps. We should put a starter mago.toml config file somewhere.
I would propose we do that all in your magp-drupal project, but should we move it to drupal.org? On Github we cannot give Drupal contribution credits.
Comment #11
klausiAh sorry, I misunderstood. So it looks like the mago formatter is not ready yet? We have lots of formatter rules in Coder that would be great to support in Mago.
So we do need this issue afterall because the Mago formatter does not support checking doc comments for example?
Comment #12
klausiI think the mago lint work is great, integrated into graphql module: https://git.drupalcode.org/project/graphql/-/merge_requests/117
I decided to enable the halstead lint rules and did some light refactoring. halstead totally makes sense to prevent huge functions.