Ongr Strict Standard Laravel Package

Product Decisions This Supports

• Whether code style becomes a merge gate. The package is a concrete, opinionated rule set — strict PSR-2 layered over Squiz sniffs — not a runtime library. Evaluating it forces the decision that actually matters: do we block PRs on style, warn only, or leave it to review? That choice moves cycle time more than the tool choice does.
• PSR-2 vs PSR-12 vs house style. Adopting this standard is implicitly a decision to freeze a 2015-era PSR-2 baseline. As a PM you use it as the fork in the road: standardize on a familiar-but-deprecated baseline, or invest once in a modern ruleset.
• Build vs buy vs fork. The artifact is a ruleset definition plus sniffs — a senior engineer can reproduce an equivalent in about a day. That reframes "adopt" as "copy the spec," which changes the procurement and maintenance math entirely.
• Tech-debt roadmap sequencing. Running any strict standard against a legacy codebase yields a violation count sliceable by directory or service. That's usable input for prioritizing cleanup sprints and for choosing a ratchet ("no new violations") over a big-bang reformat.
• Definition of Done and review etiquette. A named, versioned standard moves style arguments out of code review and into a document — a real, if soft, lever on reviewer friction and onboarding variance.
• Dev-tooling dependency policy. With an archived repo and zero dependents, this is a low-stakes rehearsal for the policy question you actually care about: what do we require of require-dev tooling (maintenance, PHP version support, license, CVE surface) before it lands in the lockfile?

When to Consider This Package

Consider it when:

• You maintain a PHP 5.x/7.0-era codebase pinned to PHP_CodeSniffer 2.x, where modern rulesets won't install, and you need a stricter-than-default PSR-2 baseline now.
• You want a reference spec, not a dependency: fork or copy the ruleset as a checklist for what "strict" means to your team, then port the rules you agree with onto a maintained tool.
• You're doing a one-off legacy audit and want an opinionated, zero-config strictness profile to generate a first violation baseline.
• The team already has ONGR/Symfony-shop familiarity and surrounding conventions in place.

Look elsewhere when:

• You're on PHP 8+ or PHP_CodeSniffer 3.x/4.x. A ruleset last released in June 2015 predates that tooling generation; compatibility is unverified and likely means pinning EOL PHPCS and an EOL PHP runtime — a security and hiring cost that dwarfs any style benefit.
• You need maintenance, security patching, or vendor support. Archived repo, 13 stars, 0 dependents: effectively no upstream and no community to absorb breakage.
• PSR-12 or Laravel conventions are the target. Use PHP_CodeSniffer 3 with slevomat/coding-standard on a PSR-12 base, or Laravel Pint if you're on Laravel — both actively maintained and installable today.
• You want autofixing at scale; PHP-CS-Fixer or Pint give a better fix-and-verify loop than a sniff-only standard.
• You need anything beyond formatting and naming — typing and architecture belong to PHPStan/Psalm, not this.

Recommended posture: do not add it as a require-dev dependency. Treat it as a read-only artifact — mine the ruleset, reproduce the valuable subset on a maintained standard, and spend the saved maintenance budget on a CI ratchet instead.

How to Pitch It (Stakeholders)

For executives (one paragraph). This is a code-style rulebook from 2015, not a product component — it ships no runtime code and nothing customers see. Its value to us is as a free, opinionated template: it shows what a "strict" baseline looks like and lets us decide cheaply whether style should be enforced automatically in CI. I do not recommend adopting it as a dependency: it's archived, unreleased since 2015, used by no other packages we can find, and predates the current generation of PHP tooling. Cost of adopting is low in dollars but high in risk (stale runtime and tooling pinning); the benefit is achievable in roughly a day of engineering by reimplementing the rules we like on a maintained standard. Recommendation: use as reference, do not depend.

For engineering (short brief). ongr/ongr-strict-standard is a PHPCS ruleset — strict PSR-2 layered on Squiz sniffs, MIT, last tagged June 2015, archived, 13 stars, 0 dependents. Two facts make it an evaluation artifact rather than a dependency: (1) it targets the PHPCS 2.x era, so on PHPCS 3/4 and PHP 8 you'd be pinning EOL tooling just to run it; (2) with no upstream, any incompatibility is ours to fix forever. What's worth taking is the decisions embedded in the ruleset — strictness levels, spacing/ordering/naming choices, and which Squiz sniffs the authors treated as non-negotiable. Concretely: run it once on a branch to produce a violation baseline, keep the ~20 rules we actually agree with, encode them as a PHP_CodeSniffer 3 ruleset using slevomat/coding-standard on a PSR-12 base (or Pint if we standardize on Laravel), and wire that as a non-blocking CI report first, then a ratchet ("no new violations") once the baseline is stable. If we later need autofix at scale, add PHP-CS-Fixer or Pint rather than extending a hand-rolled ruleset. Net: the package is a free spec; the deliverable is our own maintained standard, and we shouldn't carry a dead dependency to get it.