Weave Code
Code Style Laravel Package
ibexa/code-style
Ibexa Code Style packages the coding standards used across Ibexa projects, bundling PHP CS Fixer configuration plus related CI, IDE, Git hook, and GitHub contribution templates. Install it as a dev dependency with a tilde constraint and reuse the Ibexa ruleset in your own projects.
At a glance
Frequently asked questions about Code Style
- What is ibexa/code-style and can I use it in a Laravel project?
- ibexa/code-style is a development-only Composer package that ships Ibexa's PHP CS Fixer configuration factory, custom fixer rules, optional parallel execution, and CI, IDE, and Git hook helpers. It has no Laravel service provider or framework coupling, so you can add it to a Laravel app and point it at your app, src, and tests directories. The factory simply returns a PhpCsFixer\Config object that you extend with your own Finder and rules.
- How do I install and configure ibexa/code-style in a Laravel application?
- Run composer require --dev ibexa/code-style:~2.3.1, then create a .php-cs-fixer.php in your project root that instantiates Ibexa\CodeStyle\PhpCsFixer\InternalConfigFactory, optionally calls withRules(), calls buildConfig(), and sets a PhpCsFixer\Finder over your source and test folders. Execute vendor/bin/php-cs-fixer fix to apply the standard. No migrations, config publishing, or service providers are involved.
- Does ibexa/code-style follow SemVer, and which Composer constraint should I use?
- No, the package explicitly does not follow a strict SemVer BC promise; backward compatibility is guaranteed within a single minor release rather than across a major version. That is why the README recommends a tilde constraint with a full version, for example ibexa/code-style:~2.3.1, which limits Composer to 2.3.x patch releases. Treat every patch as potentially formatting-changing and review the diff after upgrading.
- How do I add or override rules to match Laravel coding conventions?
- Pass an array of PHP CS Fixer rules to $factory->withRules([...]) before you call buildConfig(); those rules are layered on top of the Ibexa ruleset so you can add Laravel-friendly conventions or override ones that clash. You can, for example, adjust namespace handling, class element ordering, or spacing without abandoning Ibexa's baseline. Keep the overrides in version control so CI and local runs stay identical.
- How do I enable parallel runs of PHP CS Fixer with this package?
- Call $factory->runInParallel() before buildConfig(), or use the static shortcut InternalConfigFactory::build(runInParallel: true). Parallel execution is handled by PHP CS Fixer itself and speeds up runs over large codebases such as an app directory plus tests. No extra dependency is needed beyond the package.
- How does rule set selection work, and can a composer.json branch-alias change my formatting?
- Since v2.3.1 the factory resolves the rule set by first reading a branch-alias declared in the root composer.json and only then falling back to a guessed version, and the release also adds an Ibexa 6.0 rule set targeting PHPUnit 11. In a Laravel monorepo that defines its own alias, such as dev-main mapped to 1.x-dev, that auto-detection can pick an unexpected rule set and produce different formatting locally versus in CI. Pin the desired rule set explicitly in your configuration, verify it on one representative branch, and snapshot fixer output in CI.
- Does ibexa/code-style conflict with Laravel Pint?
- They are separate tools that both wrap PHP CS Fixer, so they overlap rather than integrate; running both with different rule sets in the same pipeline will fight over formatting. Pick one as the source of truth for style and, if you adopt Ibexa's standards, keep Pint out of the pre-commit and CI formatting steps. Laravel Pint is the lower-friction choice for greenfield Laravel apps, while this package makes more sense for teams standardizing on Ibexa conventions.
- Which PHP CS Fixer and PHPUnit versions does it target, and what about older Laravel versions?
- v2.3.1 pins PHP CS Fixer to 3.90.0 with constraints relaxed enough to coexist with Symfony 7 and 8 components, which mainly removes a potential Composer conflict for Laravel projects that pull newer Symfony packages. The new Ibexa 6.0 rule set targets PHPUnit 11 tooling, so Laravel 11 and 12 projects on the PHPUnit 10/11 line fit it, while older Laravel lines on PHPUnit 9 or 10 should stay on the earlier rule sets. Confirm the resolved fixer version in composer.lock before rollout, because formatting behavior shifts with the fixer release.
- Can I use ibexa/code-style in CI, Git hooks, and IDEs like PHPStorm or VSCode?
- Yes. Commit a .php-cs-fixer.dist.php so PHPStorm and VSCode extensions can detect the rules, and add a vendor/bin/php-cs-fixer fix --dry-run --diff step to GitHub Actions or GitLab CI to fail builds on style drift. The package also ships Git hook and CI plugin helpers so pre-commit checks match what CI enforces.
- What license does ibexa/code-style use, and is it free for commercial Laravel applications?
- The repository states the source is available under the Ibexa Business Use License Agreement version 2.4 or later, granted through a valid Ibexa DXP subscription, alongside other licenses listed in the repository. That makes license review a required step before adopting it in a commercial Laravel product, so read the LICENSE file and confirm terms with Ibexa. If you need a permissive license, Laravel Pint or PHP CS Fixer with your own ruleset avoids the question entirely.
Weaver
How can I help you explore Laravel packages today?