Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Coding Standard Laravel Package

flaconi/coding-standard

A Composer package from Flaconi that bundles a shared PHP coding standard, providing PHP_CodeSniffer rules and configuration to enforce consistent style across Laravel/PHP projects. Install via Composer and run the included ruleset locally or in CI.

View on GitHub
Deep Wiki
Context7

Getting Started

The package is a PHPCS ruleset, not a runtime library — you install it as a dev dependency and point PHPCS at it.

composer require --dev flaconi/coding-standard

Because the package is archived (last release 2021-11), pin it explicitly and expect to vendor or fork it rather than rely on updates. Confirm the ruleset path after install:

composer show flaconi/coding-standard
ls vendor/flaconi/coding-standard/

Look for ruleset.xml (usually vendor/flaconi/coding-standard/Flaconi/ruleset.xml or at the package root — check the installed.json phpcs config or just find vendor/flaconi -name '*ruleset*.xml'). That file is your source of truth for what's enforced; read it before adopting.

Wire it into phpcs.xml.dist at your project root:

<?xml version="1.0"?>
<ruleset name="MyProject">
    <rule ref="Flaconi"/>
    <file>app</file>
    <file>src</file>
    <file>tests</file>
    <arg name="extensions" value="php"/>
    <arg name="colors"/>
</ruleset>

Then the first use case is always the same — baseline the existing codebase before you turn it on in CI:

vendor/bin/phpcs -p --report=summary
vendor/bin/phpcbf -p   # auto-fix what you can, review the diff

Only once the diff is reviewed and committed should you wire phpcs into CI as a blocking step.

Implementation Patterns

Composer scripts for consistency. Put both commands behind Composer so every developer and CI job runs the identical invocation:

"scripts": {
  "cs": "phpcs -p -s",
  "cs:fix": "phpcbf -p"
}

Two-phase adoption. Run phpcbf first to collapse thousands of formatting violations into one mechanical commit, then commit the remaining manual fixes separately. Never mix a phpcbf run with functional changes — the diff review becomes impossible and you lose git blame value on every touched line.

Per-path rule relaxation rather than global disabling. When the legacy tests/ directory trips the standard, scope an exclusion instead of dropping the rule everywhere:

<rule ref="Flaconi">
    <exclude name="Flaconi.NamingConventions.Something"/>
</rule>
<rule ref="Flaconi">
    <exclude-pattern>tests/fixtures/*</exclude-pattern>
</rule>

Editor integration. Point PhpStorm at the project phpcs.xml.dist (Settings → PHP → Quality Tools → PHP_CodeSniffer, set the interpreter and configuration file), or use the shepherd/phpcs extension for VS Code. Getting this working before enabling CI prevents the whack-a-mole of fixing style only at the merge gate.

CI as a separate, fast job. Because a coding standard is a pure static check it doesn't need the database or a built container. Run it as its own job alongside (not after) unit tests so it fails in seconds:

- run: composer install --no-progress
- run: vendor/bin/phpcs -p -s --report=checkstyle --report-file=cs.xml

Emit checkstyle when your CI renders inline annotations; use the default full report locally for readable context around each violation.

Baseline instead of whack-a-mole for large legacy trees. If phpcbf can't safely fix existing code (generated files, third-party vendored code), generate a baseline and commit it, then enforce "no new violations":

vendor/bin/phpcs --report=json > baseline.json   # or use a baseline tool

This is a common pattern for standards you can't retrofit in one PR.

Gotchas and Tips

The archive status is the headline gotcha. With no releases since 2021-11 and zero dependents, this package will not receive PHPCS-version-compatibility fixes. PHPCS has since moved through 3.x and now 4.x; internal sniffs (Tokenizers, AbstractSniff, and especially Slevomat-derived sniffs) have changed signatures. Pin both squizlabs/php_codesniffer and whatever coding-standard package this extends to versions known to work together, and be prepared to fork the ruleset into your own repo (often just copying ruleset.xml and dropping the dependency) rather than staying on an unmaintained path.

Transitive ruleset dependency. Most Flaconi-style standards extend slevomat/coding-standard or doctrine/coding-standard. If you install this package standalone, PHPCS may throw Referenced sniff "SlevomatCodingStandard." does not exist at load time. Inspect the <rule ref="..."> entries in the ruleset and add those standards as explicit dev dependencies at compatible versions.

installed_paths surprises. Composer's phpcs-standard installer plugin puts the standard under vendor/flaconi/coding-standard/, but PHPCS only auto-discovers standards that declare type: phpcs-standard in composer.json and are installed via a plugin-enabled Composer. If you run with --no-plugins (common in hardened CI), the standard won't be registered and ref="Flaconi" fails silently-ish ("no sniffs found"). Fix by setting the path explicitly:

<config name="installed_paths" value="vendor/flaconi/coding-standard"/>

Rule-name drift breaks exclude name=. If you upgrade the standard (or fork it), the sniff names in your phpcs.xml.dist exclusions may no longer match. PHPCS warns Referenced sniff ... does not exist — treat those warnings as errors in CI, otherwise your suppressions quietly become dead config after every bump.

phpcbf is not safe on non-formatting rules. Auto-fix will happily rewrite things like unused imports or type hints in ways that occasionally break edge cases. Run phpcbf on a clean working tree, run your test suite after, and only then commit. Never run it as a pre-commit hook on staged files without review.

Use -s to see sniff codes. Violations show a human-readable message by default; add -s (or --report=full --show-sources) to get the Standard.Category.Sniff identifier you need for targeted exclusions and for searching issues.

Line-length and generated-code exclusions. PHPCS will scan var/cache, migrations, and generated proxies if they're under your <file> paths. Add <exclude-pattern> entries early (e.g. */migrations/*, */storage/*) — nothing saps trust in a standard faster than flagging autogenerated code.

Pre-commit friction. Once the standard is active, a strict ruleset can make every commit feel like a wall. Consider gating only the changed lines in a pre-commit hook (e.g. via phpcs-changed or your own git diff --name-only --diff-filter=ACM wrapper) while enforcing the full ruleset in CI.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment
uni-method/symfony-lib