- How do I install realodix/haiku in a Laravel project?
- Install it as a dev dependency with composer require --dev realodix/haiku. It plugs into your PHP-CS-Fixer configuration rather than into your application, so there is no service provider to register, no migrations to run and no config to publish. After installing, reference the preset in your .php-cs-fixer.dist.php and run php-cs-fixer fix locally to see the result.
- Does realodix/haiku support Laravel 10 and Laravel 11?
- Because realodix/haiku is a PHP-CS-Fixer ruleset, it never boots inside your Laravel application and imposes no Laravel or PHP runtime constraints of its own. The real compatibility surface is the PHP-CS-Fixer version it builds on and the rule names your project config references. That means it can be used across Laravel 8, 9, 10, 11 and newer codebases as long as the underlying fixer requirements are satisfied.
- How do I use the haiku preset in .php-cs-fixer.dist.php?
- The package is consumed at config level: your .php-cs-fixer.dist.php points at the preset and PHP-CS-Fixer resolves the rule set when the fixer runs. You can extend or override individual rule names in your setRules() array, or wrap the preset in your own custom rule set. That config file is effectively the only integration surface, which is also exactly where rule removals or renames will surface as hard errors.
- Is realodix/haiku safe to run in a CI pipeline?
- Yes, it is built for the developer toolchain, so it fits naturally into a pre-commit hook or a CI static-analysis stage alongside any Laravel repo already using PHP-CS-Fixer. The caveat is that new detections can turn previously green branches red on the next dependency refresh even when no application code changed. Pin the version and run a dry-run diff before rolling a bump into shared pipelines.
- Why did upgrading to 1.13.32 break my build with an unknown rule error?
- Version 1.13.32 removed the removeUnnecessaryWildcard fixer rule, and any config that names it explicitly in setRules() or in a custom preset extension will fail with an unknown-rule error. Grep for removeUnnecessaryWildcard across .php-cs-fixer.php, .php-cs-fixer.dist.php, composer.json scripts and any shared internal presets, then remove or replace the reference before running the fixer. Because the removal shipped under a patch bump, a permissive ^1.13 constraint pulls it in silently on a fresh composer install.
- Should I pin realodix/haiku to an exact version?
- Yes. Since a rule removal shipped in a patch release, pinning to a known-good version such as 1.13.31 exactly is the highest-value safeguard against future silent breakage. A caret constraint like ^1.13 will absorb any subsequent patch-level removals the same way. Bump deliberately on a scratch branch, run the fixer and review the diff before merging.
- Do the two new lint rules in 1.13.32 have autofixers?
- The release adds two detections: one for a bad cosmetic rule separator and one for a wrong domain separator. Whether they ship with fixers, and whether they are part of the default preset or opt-in, is the key question and determines whether the impact is a single fix run or manual remediation across the codebase. Run php-cs-fixer fix --dry-run --diff to enumerate findings, then cluster the violation counts by directory to size the work.
- How does realodix/haiku compare to other Laravel code style tools?
- realodix/haiku distributes custom detection rules and autocorrectors as an opinionated PHP-CS-Fixer preset via a Composer dev dependency, rather than being a runtime tool or a framework feature. It is deliberately minimal, with a small API and no heavy dependencies, which makes it easy to drop into small projects and utilities. If you already use PHP-CS-Fixer with another rule set, moving to haiku is a config-level swap, and running a dry-run diff with both presets is the most reliable way to compare output.
- Should realodix/haiku be a production dependency?
- No. It is a dev dependency and must never enter your production autoload or your deploy artifact. Install it with require-dev and exclude it from production installs using composer install --no-dev. It has no runtime code path, no security surface and no interaction with your application container or framework bootstrapping.
- Is realodix/haiku actively maintained and does it follow semver?
- The package is a small, minimalist Composer tool with a low blast radius, so maintenance overhead is naturally low. That said, 1.13.32 raises legitimate semver questions because a fixer removal shipped as a patch rather than a minor or major release. Before depending on it long term, ask the maintainer whether the removeUnnecessaryWildcard removal is permanent, whether it was documented as breaking, and whether a retroactive semver correction is planned.