Download the PHP package spryker/architecture-sniffer without Composer

Architecture Sniffer

Architecture Sniffer for Spryker core, eco-system and applications.

The package ships two independent rulesets. Use the one that matches what you are working on:

Make sure the sniffer is installed as a require-dev dependency:

Common to both: lower priorities (higher numbers) always include the higher priorities (lower numbers) — a run at priority 3 also reports 1 and 2.

Spryker Core Development

Use the core ruleset src/ruleset.xml.

Priority Levels

• 1: API and critical
• 2: Non critical (nice to have)
• 3: Experimental (inspected code needs further fixing)

We use and recommend minimum priority 2 by default for local and CI checks.

Usage

When using Spryker you can use the Spryker CLI console command:

Verbose output is recommended here.

Or run it manually:

Including the sniffer in PHPStorm

Add a new custom ruleset under Editor -> Inspections -> PHP -> PHP Mess Detector validation and name it Architecture Sniffer. The ruleset is defined in vendor/spryker/architecture-sniffer/src/ruleset.xml.

Under Framework & Languages -> PHP -> Mess Detector set the path to your phpmd (vendor/bin/phpmd), then run Validate to confirm it works.

Spryker Project Development

Use the project ruleset src/Project/ruleset.xml. It bundles adapted PHPMD, Spryker architecture, and project-only rules.

Priority Levels

• 1: Critical
• 2: Major
• 3: Medium
• 4: Minor

Recommended minimum priority per project maturity:

• 1 and 2: recommended for all projects, including those with legacy code.
• 3: recommended for all new projects.
• 4: recommended for a modern AI-assisted development flow.

Usage

Setup for the project & customizing rules

The project ruleset is meant to be tuned per project. Create a thin project-level phpmd.xml in the project root (PHPMD's conventional default filename) that references the vendor project ruleset, then layer your customizations on top of it — exclude modules, change priorities, or adjust rule properties without touching the vendor package:

After that, run phpmd against your project-level ruleset instead of the vendor one, and change it freely for project needs:

The commands below use this project-level path.

Local Code Review Usage

For a local review, save the report to JSON and format it into a grouped, human-readable summary.

Save the report (scan all priorities for an AI-assisted review):

or

Format it:

Without <output.txt> the formatted report is printed to stdout.

Baseline

Adopt the ruleset on an existing project without refactoring legacy code first: generate a baseline of the current violations and only fail on new ones.

Use --update-baseline to drop violations that no longer exist. Store the baseline in version control and shrink it over time.

Debugging

Enable Xdebug for phpmd to step through rule code:

Writing new sniffs

Add them to inside src folder and add tests in tests with the same folder structure. Don't forget to update ruleset.xml.

Every sniff needs a description as full sentence:

Every sniff needs to implement either the ClassAware, FunctionAware, InterfaceAware, or MethodAware interface to be recognised. To validate that sniffer recognises your rule, check if your rule is listed in Zed UI > Maintenance > Architecture sniffer.

Also note:

• The rule names must be unique across the rulesets.
• Each rule should contain only one "check".
• Each rule always outputs also the reason (violation), not just the occurrence.

Setup

Run

and

Testing

Don't forget to test your changes:

Running code-sniffer on this project

Make sure this repository is Spryker coding standard conform:

If you want to fix the fixable errors, use

Once everything is green you can make a PR with your changes.