- What is tightenco/tighten-coding-standard used for?
- It is an opinionated PHP_CodeSniffer ruleset for Laravel projects that composes PSR-12 conventions with Laravel-flavored checks and Tighten-specific sniffs. It enforces consistent code style and flags common issues with very little configuration. It adds no runtime capability of its own, so its value comes entirely from uniform enforcement across repositories, usually in CI.
- How do I install tightenco/tighten-coding-standard in a Laravel project?
- Install it as a dev dependency with composer require --dev tightenco/tighten-coding-standard. Then add a phpcs.xml or phpcs.xml.dist that references the standard shipped by the package in a rule element, and run vendor/bin/phpcs against your source paths. Because it is a PHPCS external standard, it must be registered through installed_paths, which the Composer installer plugin usually handles for you.
- Do I have to allow dealerdirect/phpcodesniffer-composer-installer in Composer?
- In practice yes. PHPCS external standards live outside normal autoloading, so they need installed_paths registration, and the standard way to automate that is the dealerdirect installer plugin, which Composer 2.2+ blocks until you allow it under config allow-plugins. Because that plugin touches autoloading and the filesystem, expect a security review and platform-team ownership if it goes into a shared CI base image.
- Should I use Tighten Coding Standard instead of Laravel Pint?
- They overlap and will fight each other. Pint is PHP-CS-Fixer based while this package is PHP_CodeSniffer based, so running both produces duplicate findings and potentially conflicting auto-fixes. Pick one formatter-of-record and record that decision before rolling out, because reversing it later means re-normalizing the whole tree. This ruleset fits teams already running PHPCS or needing baselined, changed-files-only enforcement.
- Does the ruleset support my Laravel and PHP versions?
- Laravel version support is mostly indirect here: the practical constraints are your PHP version and how well the sniffs understand newer syntax. PHPCS sniffs track PHP tokenizer behavior, so features like enums, readonly properties, attributes, and first-class callables can produce false positives until upstream catches up. Validate against your actual PHP matrix and check the package's own composer.json constraints rather than assuming a support table exists.
- Which PHP_CodeSniffer version does it pin, and what happens when I upgrade?
- Pin the PHPCS minor and treat upgrades as reviewed changes rather than routine dependency bumps. New language features historically trigger false positives, and PHPCS 4.x is a breaking release for standards authors, so a loose constraint can turn a composer update into a flood of new or vanished findings. Keep a committed fixture with known violations that CI must reject, and gate every PHPCS upgrade behind that smoke test.
- How do I enforce the standard in CI and prove it is actually running?
- Run vendor/bin/phpcs in the pipeline with an explicit standard, explicit paths, and a fail-on-error exit code. Add a smoke test: a committed fixture file with known violations that the build must reject on every run. Silent non-enforcement is the biggest risk with this kind of gate, because a standard that fails to register can error out or run an effectively empty ruleset, giving you a green build that enforced nothing. Distribute matching editor configuration so local results agree with CI.
- Can phpcbf auto-fix violations, and are the fixers safe?
- phpcbf fixes only a subset of sniff violations, and coverage varies by sniff, so expect some findings to stay manual. Before adopting it broadly, run phpcbf over a representative branch and review the diff for semantic rewrites or damaged docblocks. On legacy codebases, combine it with a baseline so you fix changed files instead of reformatting the entire tree in one unreviewable commit.
- Will this package end up in my production build?
- It should not, and preventing that is cheap. Keep it in require-dev and build release artifacts with composer install --no-dev, then add an explicit build assertion that vendor/bin/phpcs and the ruleset are absent from the shipped image. The package has no runtime surface, so any appearance in production is a packaging mistake rather than a functional need.
- Is the package actively maintained, and should I fork it or pin it?
- Assume you are the only consumer: at evaluation time the latest visible release was 1.0.2 with no stars and no dependents, and there is no community triage validating behavior on your PHP matrix. That argues for pinning the exact version and treating it as vendor-authored sample configuration rather than a supported product. Fork only if you need changes upstream will not take, and name an owner for phpcs.xml, the baseline, and the suppression policy either way.