interitty/code-checker

Code checker script provides the way to check the quality of the Interitty codes.

v1.0.17 2026-06-23 09:52 UTC

Requires

• php: ~8.5
• ext-simplexml: *
• ext-tokenizer: *
• ext-xml: *
• ext-xmlwriter: *
• dg/composer-cleaner: ~2.2
• friendsofphp/php-cs-fixer: ~3.92
• phpmd/phpmd: ~2.15
• phpstan/extension-installer: ~1.4
• phpstan/phpstan: ~2.1
• phpstan/phpstan-deprecation-rules: ~2.0
• phpstan/phpstan-nette: ~2.0
• phpstan/phpstan-phpunit: ~2.0
• phpstan/phpstan-strict-rules: ~2.0
• slevomat/coding-standard: ~8.25
• spaze/phpstan-disallowed-calls: ~4.7
• squizlabs/php_codesniffer: ~4.0

Suggests

• phpunit/php-code-coverage: Add possibility to generate PHPUnit code coverage report compatible with GitLab
• phpunit/phpunit: Run phpunit tests when the root directory of the project contains the phpunit.xml file

MIT

• Martin Štefan
• Pavel Železný

• php
• automation
• standards
• psr
• qa
• static-analysis
• coding-standards
• interitty

Published on Packagist.org on 2026-06-23 07:56 UTC

README

Code checker script provides the way to check the quality of the Interitty codes.

Requirements

• PHP >= 8.5

Installation

The best way to install interitty/code-checker is using Composer:

composer require --dev interitty/code-checker

To install the git hooks, simply run the following command in the root dir of the project (where .git and vendor folders are located):

./vendor/bin/git-hook --install

For macOS users, it is necessary to unify the coreutils with the Linux users simply by running the following command:

brew install coreutils

Usage

If the global PATH property contains a path to the folder where the code-check script is, it is possible to run the command directly in the project folder without any arguments and check if there is an error in the code.

code-checker

Optionally the project folder can be specified by the relative or absolute path

code-checker --ignore-path=./interitty/project/vendor ./interitty/project

More than one path can also be checked by concatenating the --path parameter.

code-checker --base-dir=./interitty/project --path=./src --path=./tests

The code-checker will return the lowest exit code that happens thru execution. When the exit code is 0, everything is OK in the project. This was used in the git-hook, which can be used as git pre-commit, commit-msg, pre-push hook, or in the CI-CD pipeline.

The git-hook used as commit-msg also checks the commit message and allows to skip checks for "work in progress" commit where the message starts on WIP: or simply ., but not for pushing into protected branches (master, test, develop).

Checkers setup

In some cases, like when a new version of PHP comes, it can be useful to set up the list of enabled checkers. Because of that, there is an optional --checks=<CHECKS> parameter that allows specifying the enabled checks by a comma-separated list of their names. The default value for the list contains all of them.

code-checker --checks=composer_checker,static_analysis,mess_detector,code_sniffer,markdown_checker,phpunit

An alternative way, useful for CI-CD pipelines, is to set up the CHECKS environment variable.

CHECKS=composer_checker,static_analysis,mess_detector,code_sniffer,markdown_checker,phpunit code-checker

Due to a PHP8 Unexpected token bug can be handy to set up globally a CHECKS environment variable to disable a mess_detector, for example in ~/.bashrc file.

Composer Checker

The composer_checker step lints composer.json against Interitty packaging conventions. It is backed by the interitty/composer-checker package and executed through vendor/bin/composer-checker check. The bundled interitty ruleset checks required fields, support sub-fields, keyword ordering, the license string notation, the require.php constraint operator and the declaration of used PHP extensions as ext-* requirements.

The ruleset can be customised per project through a composer-checker.neon file in the project root, which code-checker passes to the checker automatically when present. Fixable violations are corrected in place when code-checker runs with --fix. See the package documentation for the full list of sniffs and their options.

Markdown Checker

The markdown_checker step lints (and with --fix auto-corrects) the project's Markdown files via the bundled interitty/markdown-checker. It runs through the bin/markdown-checker thin wrapper, which interprets only a few wrapper-level options (--config, --docker-container, --xdebug, --help) and passes every other option (e.g. --fix, --ignore-path, --report, --sniff-arg) and all positional paths straight through to markdown-checker.

A project can customise the rules by placing a markdown-checker.neon file in the project root; it is auto-detected and used when present, and typically extends the bundled interitty ruleset via extends: interitty.

Project-level PHPCS configuration

A project can override the default Interitty PHPCS ruleset by placing a ruleset file in the project root. When code-checker runs code_sniffer, it looks for one of the following file names in the project root (the same auto-discovery order as phpcs itself, first match wins):

1. .phpcs.xml
2. phpcs.xml
3. .phpcs.xml.dist
4. phpcs.xml.dist

If none of these is present, the bundled Interitty standard from interitty/php-codesniffer is used as a fallback — existing projects without a project-level file keep their current behavior.

The project ruleset usually imports the Interitty standard by name (registered automatically via the dealerdirect/phpcodesniffer-composer-installer Composer plugin) and then adjusts individual sniffs through their public properties:

<?xml version="1.0"?>
<ruleset name="ProjectStandard">
    <rule ref="Interitty"/>

    <rule ref="Interitty.Functions.MethodParameterOrder">
        <properties>
            <property name="methodExceptions" type="array">
                <element value="App\Foo\Bar::baz"/>
            </property>
        </properties>
    </rule>
</ruleset>

This mechanism configures sniffs — it does not silently suppress findings. Exceptions are listed explicitly in the project ruleset, are visible in the repository, and apply only to the methods named there. To opt out of a sniff entirely, omit it from the project ruleset rather than disabling it inline.

When the checked project has a vendor/autoload.php, both code-checker (when running code_sniffer) and the standalone bin/phpcs IDE wrapper pass it to PHPCS via the --bootstrap option. Sniffs that resolve class ancestors through reflection can then autoload the project's own classes and detect inherited methods; without the bootstrap they would silently treat every ancestor as unknown.

Project-level PHPMD configuration

A project can override the default Interitty PHPMD ruleset by placing a ruleset file in the project root. Both code-checker (when running mess_detector) and the standalone bin/phpmd IDE wrapper look for one of the following file names in the project root (the same auto-discovery order as PHPCS, first match wins):

1. .phpmd.xml
2. phpmd.xml
3. .phpmd.xml.dist
4. phpmd.xml.dist

If none of these is present, the bundled src/phpmd/rulesets/interitty.xml ruleset is used as a fallback — existing projects without a project-level file keep their current behavior.

Unlike PHPCS, PHPMD has no registry of named standards, so the project ruleset imports the bundled Interitty ruleset by path through a <rule ref="…"/> reference and then adjusts individual rules through their public properties:

<?xml version="1.0"?>
<ruleset name="ProjectRuleset"
         xmlns="http://pmd.sf.net/ruleset/1.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd">
    <rule ref="vendor/interitty/code-checker/src/phpmd/rulesets/interitty.xml"/>

    <rule ref="rulesets/codesize.xml/ExcessiveClassComplexity">
        <properties>
            <property name="maximum" value="60"/>
        </properties>
    </rule>
</ruleset>

Adjust the <rule ref="…"/> path to wherever interitty/code-checker is reachable from the project root (e.g. vendor/interitty/code-checker/src/phpmd/rulesets/interitty.xml).

The bin/phpmd wrapper gives the project ruleset precedence over a ruleset passed as a positional argument; --force-ruleset=<PATH> remains a hard override above both. A phpmd.xml (or variant) passed as a check target (e.g. NetBeans on-save of the config file itself) is silently skipped.

Settings

There are some more settings you can need to fit your suit.

Script parameter	Description
--base-dir="…"	The base directory of all paths, which is also used for truncating output messages.
--bin-dir="…"	Path of the composer bin dir where are all executables located.
--check_arguments_composerchecker="…"	Optional arguments for Composer checker.
--check_arguments_markdownchecker="…"	Optional arguments for Markdown checker.
--check_arguments_phpcs="…"	Optional arguments for PHP CodeSniffer.
--check_arguments_phpcsfixer="…"	Optional arguments for PHP Coding Standards Fixer.
--check_arguments_phpmd="…"	Optional arguments for PHP Mess detector.
--check_arguments_phpstan="…"	Optional arguments for PHP Static Analysis Tool.
--check_arguments_phpunit="…"	Optional arguments for PHP Unit.
--checks=<CHECKS>	Comma-separated list of enabled checks. See the example above for the default value.
--color	Enable color output.
--colors="…"	Specify the colour output in detail.
--debug, -vv	Increase verbosity level to show also debug messages.
--fail-fast	Stop processing other tests when the first error happens.
--fix	Try to fix automatically what is possible.
--generate-baseline	Generate PHPStan baseline file for the current project.
--help, -h	Show the help message.
--ignore-path="…"	The path that should be excluded from checks.
--memory-limit="…"	Specifies the memory limit in the same format php.ini accepts.
--no-color	Disable color output.
--no-output	An alias for --quiet.
--path="…"	The optional way to specify the path for files or folders for processing.
--pro	Launch PHPStan Pro.
--quiet, -q	Decrease verbosity level to 0 to hide all output.
--ruleset="…"	PHPCS ruleset to use; overridden by a project-level ruleset file. Default: Interitty.
--verbose, -v	Increase the verbosity level so that warning messages are also displayed.
--xdebug	Allow running with Xdebug for debugging purposes.

Environment variables

Some of the settings can also be set by the environment variable.

Environment variable	Description
CHECK_ARGUMENTS_COMPOSERCHECKER="…"	Optional arguments for Composer checker.
CHECK_ARGUMENTS_MARKDOWNCHECKER="…"	Optional arguments for Markdown checker.
CHECK_ARGUMENTS_PHPCS="…"	Optional arguments for PHP CodeSniffer.
CHECK_ARGUMENTS_PHPCSFIXER="…"	Optional arguments for PHP Coding Standards Fixer.
CHECK_ARGUMENTS_PHPMD="…"	Optional arguments for PHP Mess detector.
CHECK_ARGUMENTS_PHPSTAN="…"	Optional arguments for PHP Static Analysis Tool.
CHECK_ARGUMENTS_PHPUNIT="…"	Optional arguments for PHPUnit.
CHECKS="…"	Comma-separated list of enabled checks. See the example above for the default value.
CLICOLOR=1	Enable color output.
DEBUG=1	Increase verbosity level to show also debug messages.
DOCKER_DEV_CONTAINER="…"	Name of the docker container in which code-checker runs.
DOCKER_ENVS="…"	Comma-separated list of environment variable names to promote them to the docker.
GLOBAL_BASELINE="…"	Path where the PHPStan baseline file is located.
MEMORY_LIMIT="…"	Memory limit for PHP Static Analysis Tool analysis.
NO_OUTPUT=1	Decrease verbosity level to 0 to hide all output.
PHPCS_RULESET="…"	PHPCS ruleset to use; overridden by a project-level ruleset file. Default: Interitty.
VERBOSE=1	Increase the verbosity level so that warning messages are also displayed.
XDEBUG_MODE="…"	Xdebug mode passed to PHP (e.g. debug, coverage).

Docker support

If a global environment DOCKER_DEV_CONTAINER is set up and a docker container with the setup <name> settings is started, the code-checker and git-hook commands are executed in it. To set the global environment value "permanently" just add the following command into the .bashrc file or the similar file related to the shell you are using.

export DOCKER_DEV_CONTAINER="<name>"

The docker-exec script is used to run the command in the defined docker container.

docker-exec "/path/command --some-arguments /path/to/project"

Fix IDE

The IDEs help developers in many cases, but sometimes they are not so useful. In the integration between the IDEs and third-party applications, they provide the address where the project's properties file is located instead of the project address. Less complicated but still not very useful is that these applications run from the root folder instead of the project folder.

For these cases, there is a fix-ide script that detects the address containing the nbproject folder with the project properties and changes them according to the project directory.

For example the following call will detect existence of the /path/to/project-properties/nbproject folder and call the given command with the project folder, that is defined as the src.dir property in the ./nbproject/project.properties file.

#$PWD = /
fix-ide /path/command --some-arguments /path/to/project-properties

Previous command will lead to call the following one.

#$PWD = /path/to/project
/path/command --some-arguments /path/to/project

PHP Mess Detector

To run the phpmd from the IDE in the docker container with the custom ruleset, use the same-named phpmd script from the interitty/code-checker instead of the original one.

For example, when the interitty/code-checker is cloned in /opt/srv/interitty/interitty/code-checker folder, docker container is named php-fpm-dev and prefered ruleset is in ./src/phpmd/rulesets/interitty.xml, add following string into NetBeans config.

/opt/srv/interitty/interitty/code-checker/bin/phpmd --color --docker-container=php-fpm-dev --fix-ide --force-ruleset=/opt/srv/interitty/interitty/code-checker/src/phpmd/rulesets/interitty.xml

PHP CodeSniffer

To run the phpcs from the IDE in the docker container with the custom ruleset, use the same-named phpcs script from the interitty/code-checker instead of the original one.

For example, when the interitty/code-checker is cloned in /opt/srv/interitty/interitty/code-checker folder, docker container is named php-fpm-dev and prefered ruleset is the bundled Interitty standard (registered automatically via the dealerdirect/phpcodesniffer-composer-installer Composer plugin), add following string into NetBeans config.

/opt/srv/interitty/interitty/code-checker/bin/phpcs --color --docker-container=php-fpm-dev --fix-ide --force-ruleset=Interitty

PHP Coding Standards Fixer

[!note] This tool is redundant — its rules are duplicated by interitty/php-codesniffer (with auto-fix via phpcbf).

To run the php-cs-fixer from the IDE in the docker container with the custom ruleset, use the same-named php-cs-fixer script from the interitty/code-checker instead of the original one.

For example, when the interitty/code-checker is cloned in /opt/srv/interitty/interitty/code-checker folder, docker container is named php-fpm-dev and prefered ruleset is in /src/php-cs-fixer/.php-cs-fixer.php, add following string into NetBeans config.

/opt/srv/interitty/interitty/code-checker/bin/php-cs-fixer

And following string into Default Options.

--color --docker-container=php-fpm-dev --fix-ide --config=/opt/srv/interitty/interitty/code-checker/src/php-cs-fixer/.php-cs-fixer.php

PHP Static Analysis Tool

To run the phpstan from the IDE in the docker container with the custom ruleset, use the same-named phpstan script from the interitty/code-checker instead of the original one.

For example, when the interitty/code-checker is cloned in /opt/srv/interitty/interitty/code-checker folder, docker container is named php-fpm-dev and prefered ruleset is in /src/phpstan/interitty.neon, add following string into NetBeans config.

/opt/srv/interitty/interitty/code-checker/bin/phpstan --color --docker-container=php-fpm-dev --fix-ide

And following string into Configuration.

/opt/srv/interitty/interitty/code-checker/src/phpstan/interitty.neon

Occasionally it can be useful to be able to add something to ignore in PHPStan so that it is not part of the project, since the cause is already resolved and just not yet part of the current version. In this case, it is possible to generate a PHPStan baseline file into the project root or home folder.