Weave Code
Qa Tools Laravel Package
ibuildings/qa-tools
iBuildings QA Tools bundles common PHP quality checks into a single Composer package, with shared configuration and commands for code style, static analysis, and testing. It helps teams enforce consistent standards across PHP projects and streamline local development and CI workflows.
At a glance
Frequently asked questions about Qa Tools
- Is ibuildings/qa-tools a Laravel package?
- No. It ships no service provider, no facade, and no publishable config, and it has zero runtime coupling to a Laravel application. It is a Composer dev-dependency that scaffolds opinionated CLI config files such as phpcs.xml, phpmd.xml, and phpunit.xml into a project. Treat it as developer tooling, not framework integration.
- Does ibuildings/qa-tools work with Laravel 10 or Laravel 11?
- No, not practically. The last release was March 2017 and pins PHP_CodeSniffer 2.x and PHPUnit 4/5, which cannot parse PHP 8 syntax such as enums, readonly properties, attributes, or constructor promotion. Laravel 10 and 11 require PHP 8.1+, so Composer will either fail constraint resolution or install a stack that crashes on first invocation.
- How do I install ibuildings/qa-tools?
- It installs as a Composer dev-dependency and exposes an installer binary, bin/qa-tools, which scaffolds phpcs.xml, phpmd.xml, phpcpd, and phpunit.xml into your project. On modern PHP versions expect constraint resolution failures or immediate tool crashes, so confirm your PHP floor before attempting it. Installation is not the hard part; getting the pinned 2017 toolchain to run on PHP 8 is.
- What QA tools are bundled in ibuildings/qa-tools?
- The bundle wraps PHP_CodeSniffer for coding standards, PHPMD for mess detection, PHPCPD for duplicate code, and PHPUnit for tests and coverage. Each is pinned to a release-era version suited to PHP 5.6/7.x projects, and there is no PSR-12 ruleset. The durable asset is the shared configuration baseline, not the wrapper code.
- Does ibuildings/qa-tools include static analysis like PHPStan or Larastan?
- No. There is no PHPStan, Psalm, or Larastan equivalent in the bundle, so adopting it anchors your project to a static-analysis-free baseline. PHPMD performs mess detection, not type-level analysis. If type coverage is your goal, plan a separate PHPStan plus Larastan setup.
- Is ibuildings/qa-tools still maintained?
- No. The upstream repository is archived, the last release was March 2017, and it has no dependents and no security-advisory response path for its abandoned transitive dev dependencies. Do not expect patches, PHP 8 compatibility fixes, or ruleset updates. Any fork you adopt becomes your team's long-term responsibility.
- Can I run ibuildings/qa-tools in a CI/CD pipeline?
- Only in a dedicated legacy lane for PHP 7.1 or older, and even then pin it hard and isolate it. On a PHP 8.2/8.3 lane the bundled tools cannot parse modern syntax, and parse failures can masquerade as clean runs, eroding trust in the quality gate. Do not lower your modern lane's PHP floor to accommodate a 2017 toolchain.
- Will ibuildings/qa-tools cause Composer dependency conflicts?
- Very likely. It pins PHP_CodeSniffer 2.x, PHPUnit 4/5, and PHPMD/PHPCPD 2.x, which conflict with the PHPUnit 10/11, PHPCS 3.x, and PHP-CS-Fixer versions most Laravel projects depend on. Composer may refuse to resolve or install a combination that crashes when invoked. If you must run it, keep it in a separate legacy CI lane with hard version pins.
- What are the best alternatives to ibuildings/qa-tools for Laravel?
- The modern equivalent stack is laravel/pint or PHP-CS-Fixer for formatting, PHP_CodeSniffer 3.x with slevomat/coding-standard for standards enforcement, phpstan/phpstan plus larastan/larastan for static analysis, PHPUnit 10/11 or Pest for tests, and rector/rector for legacy upgrades. PHPStan's duplicate-code detection replaces PHPCPD. Together these cover everything qa-tools did, plus the type-level analysis it never offered.
- Can I reuse the ibuildings/qa-tools config files without installing the package?
- Yes, and that mine-and-replace approach is the recommended path. The package is MIT licensed, so you can extract the phpcs.xml, phpmd.xml, and phpunit.xml presets as a starting baseline and port the rules to PHPCS 3.x and PHPStan. Ship them as an internal company/qa-baseline Composer package with versioned rulesets so someone clearly owns the ruleset long-term.
Weaver
How can I help you explore Laravel packages today?