Skip to content

Instantly share code, notes, and snippets.

@nikspyratos
Created February 6, 2026 19:57
Show Gist options
  • Select an option

  • Save nikspyratos/ce992471ea4667e361818e06e089f350 to your computer and use it in GitHub Desktop.

Select an option

Save nikspyratos/ce992471ea4667e361818e06e089f350 to your computer and use it in GitHub Desktop.
Mago Pint parity
[formatter]
preset = "pint"
space-after-logical-not-unary-prefix-operator=true
space-within-grouping-parenthesis=false
inline-empty-control-braces=true
inline-empty-closure-braces=true
inline-empty-function-braces=true
inline-empty-method-braces=true
inline-empty-constructor-braces=true
inline-empty-classlike-braces=true
inline-empty-anonymous-class-braces=true
{
"preset": "laravel",
"rules": {
"no_unneeded_control_parentheses": false
}
}
@nikspyratos
Copy link
Author

For a completely default install of Pint, this is the current mago.toml config you'll need to ensure closer parity to Pint's preset.

If you're testing both tools at the same time, take note:

  • no_unneeded_control_parentheses Needs to be disabled on Pint's side as there is no equivalent format rule for this on Mago's side, though there does seem to be something from Mago that conflicts with this rule.
  • You may run into class_definition fixes from Pint's side if you're comparing the two tools on the same codebase, specifically when you're using a class with many interfaces that would get broken up according to Mago's print-width setting. I'm not exactly sure why though as class_definition should still work this way. Best fix I found was just increasing print-width.

Mago is still under rapid development, so expect this gist to be outdated pretty quickly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment