- What does zebra-north/phpcs-short-types actually do?
- It is a PHP_CodeSniffer standard that flags long-form scalar type names such as integer, boolean, double, and real in favor of the short forms int, bool, and float. It applies to PHPDoc annotations like @param, @return, and @var as well as PHP type declarations. It is a static analysis rule only, so it has no runtime footprint in your application.
- How do I install zebra-north/phpcs-short-types in a Laravel project?
- Install it as a dev dependency with composer require --dev zebra-north/phpcs-short-types. Composer 2.2 and later will prompt you to allow the dealerdirect/phpcodesniffer-composer-installer plugin, which registers the standard automatically, so make sure it is listed under config.allow-plugins. If you do not use the installer plugin, you will need to register the standard path manually via installed_paths.
- How do I add the short-types rule to my phpcs.xml ruleset?
- Add a rule entry inside your phpcs.xml or phpcs.xml.dist that references the standard and sniff code shipped by the package. The exact Standard.Sniff.Code string cannot be inferred from the package name, so check the vendor directory layout after installing to confirm it. You can then scope the rule to app/, src/, and tests/ with a file element and exclude vendor/ and generated code.
- Which PHP and PHP_CodeSniffer versions does zebra-north/phpcs-short-types support?
- You should check the composer.json constraints in the package before adopting it, since the README does not state the supported range. Sniffs bind to PHP_CodeSniffer's internal token API, and PHPCS 4.x changed tokenizer behavior and dropped older PHP support, so verify compatibility if you are on or moving to PHPCS 4. Pin your PHPCS version in CI until you have confirmed the sniff works against it.
- Does zebra-north/phpcs-short-types work with Laravel Pint?
- No, not automatically. Pint ships its own fixed ruleset and does not read phpcs.xml, so this sniff will not be honored when you run Pint. Teams that standardize on Pint should either run PHPCS as a separate CI step alongside Pint or accept that short type names are only enforced in the PHPCS lane.
- Can phpcbf auto-fix the long-form types, or is the sniff gate-only?
- That depends on whether the sniff implements addFixableError rather than plain addError, which is not stated explicitly in the package overview. Before making it a blocking gate in CI, run phpcbf against a sample file to see whether the long-form types are rewritten automatically. If the sniff is not fixable, plan for manual remediation or use it as a warning-level rule initially.
- Will the sniff flag the word boolean in normal comment prose, or only in docblock type positions?
- This is the most important behavior to verify before enabling the rule as a blocking gate. A naive word-boundary match on integer or boolean will also flag English prose such as "returns a boolean indicating success" in free-text comments. Test it against a representative file from your codebase to confirm whether it is scoped to docblock type positions or scans all comment bodies.
- Does it handle union types, nullable types, and generics like array<integer>?
- The package description does not guarantee coverage for composite types, so test these cases yourself before rollout. Union types like int|boolean, nullable forms such as ?integer, array generics like array<integer>, and PHPStan or Psalm types like positive-int should all be checked. Partial coverage produces inconsistent enforcement, which can erode team trust in the rule faster than not enabling it at all.
- Does zebra-north/phpcs-short-types add any runtime overhead or affect production?
- No. It is a static analysis sniff that runs only under PHP_CodeSniffer during development and CI, with no coupling to application code. It can be added or removed in a single commit by changing composer.json and your ruleset, with no rollback plan needed beyond reverting that change.
- Is zebra-north/phpcs-short-types actively maintained, and what should I check before adopting it?
- It is a small package from a single agency with very few stars and no dependents, so there is no meaningful maintainer SLA. The main risk is a PHPCS major version bump breaking the sniff without a prompt upstream patch, so pin your PHPCS version and watch the repo. Alternatives include adding equivalent rules through Slevomat Coding Standard or writing a custom sniff if you need long-term guarantees.