Standards Php Laravel Package

Product Decisions This Supports

• Build vs. buy for code-quality tooling. zicht/standards-php is not an application dependency — it's an opinionated phpcs ruleset distributed as a Composer package. The real decision it informs is whether your team maintains its own coding standard, adopts a vendor's, or composes one from PSR-12 plus a sniff library (Slevomat, Doctrine, etc.). This package is the "buy" option, and a cheap one to trial.
• Where to spend engineering review time. Enforcing a shared ruleset moves style debates out of pull requests and into CI. That is a roadmap-level decision: every hour of senior review spent on formatting is an hour not spent on architecture or product risk. A ruleset is one of the highest-leverage, lowest-cost interventions available for this.
• Standardizing a multi-repo / multi-team surface. If you run several PHP services or a legacy monolith plus new services, a single external ruleset is the cheapest way to make "consistent" a CI-enforced fact rather than a tribal convention. It also gives a defensible answer to "why does this file look different?"
• Onboarding and contributor ramp-up. A published standard shortens the path for new hires and contractors: the ruleset is executable documentation. This is a hiring/velocity argument more than a code-quality argument, and it's the one that tends to survive budget review.
• Static analysis roadmap sequencing. A ruleset is the lowest-rung step before PHPStan/Psalm/phan. Adopting it now establishes the CI gate and the "fix the linter" habit that later static-analysis adoption depends on. Treat it as sequencing, not as a standalone win.
• Vendor and standards-governance due diligence. The package has zero stars and zero dependents. That is a decision input in itself: it signals an internally published artifact rather than a community standard. Use cases where that's fine: reference implementation, a starting point to fork, or a checklist of sniffs you should consider. Use cases where it isn't: a long-lived, unowned dependency in a critical build pipeline.

When to Consider This Package

Consider it when:

• You are inside (or closely aligned with) the Zicht ecosystem, or you have inherited a codebase already written to these conventions — then the ruleset is documentation of existing reality and adoption cost approaches zero.
• You want an opinionated PHP standard rather than PSR-12's deliberately minimal baseline, and you do not want to own the sniff-level curation yourself.
• Your build pipeline is already phpcs-based (Composer script, CI step, pre-commit hook). Adding a ruleset is a one-line phpcs.xml include, so the trial cost is measured in minutes.
• You have a small team with no dedicated platform/tooling owner, and a curated ruleset buys you a de facto owner.
• You are evaluating standards as an input to a decision — reading its ruleset.xml is a genuinely useful way to see which sniffs a peer organization considered non-negotiable.

Look elsewhere when:

• You are on Laravel and want a default. Laravel Pint is the maintained, framework-aligned path, ships with Laravel, and is what most engineers will already expect. Choosing a third-party phpcs ruleset here creates a second toolchain and a second set of opinions.
• You need maintenance guarantees. Zero stars and zero dependents is not a quality judgment, but it is a support-signal judgment. There is no visible community to catch a broken sniff or an incompatible phpcs major version. If nobody on your team is willing to own a fork, the total cost of ownership is higher than the license suggests.
• You need modern PHP or modern PHPCS coverage. Confirm the ruleset supports your PHP version and your phpcs major version (3.x vs. 4.x) before committing; a ruleset that pins an old phpcs will block other tooling upgrades and turn into a migration project.
• You need fine-grained, explainable rules. A curated external ruleset is a black box to your engineers. If you need per-sniff rationale, custom exclusions, or gradual adoption via baseline files, composing PSR-12 + Slevomat yourself gives you a ruleset you can actually defend in review.
• You want auto-fixing. phpcs reports; phpcbf fixes a subset. If the goal is "developers never think about formatting," a formatter-first tool (php-cs-fixer, Pint) delivers more of the outcome with less friction.

Net PM read: treat this as a reference implementation and a fork candidate, not a strategic dependency. The adoption decision should be gated on a one-day spike: does it install cleanly against your PHP/phpcs versions, and how many violations does it produce on your current codebase?

How to Pitch It (Stakeholders)

To executives — one paragraph. We spend senior engineering time reviewing formatting instead of logic, and we answer "what's our code standard?" with a wiki page nobody reads. This package is a pre-built, one-line-install coding standard that turns that convention into an automated CI gate — no feature work displaced, effectively zero license cost. The catch is that it's an unmaintained single-vendor artifact (no community adoption), so I recommend a bounded one-day evaluation, then either adopt with a named internal owner or fork the ruleset into our own repo. Either way, we end up owning our standard explicitly, which is the outcome we actually want.

To engineering — the practical case. It's a phpcs ruleset on Packagist. Add it, point phpcs.xml at it, wire it into CI, and style stops being a review topic. Two caveats worth saying out loud before anyone gets attached: it has no dependents and no visible community, so it is not a safe long-term unpinned dependency; and it will fight with Pint if you're a Laravel shop, so pick one toolchain. Recommendation: run it as a read-only audit on the current codebase first to size the violation backlog, then decide between adopting it pinned, forking it, or building a PSR-12 + Slevomat ruleset we control. The audit is the deliverable; the dependency decision comes after.

To the team — what changes day to day. Nothing about how you write code that already passes review; the linter just makes it explicit and stops the same three comments from appearing on every PR. Expect a one-time cleanup diff, and expect to add a baseline or exclusion list for legacy directories rather than reformatting the world.