Pinte Laravel Package

Product Decisions This Supports

• Formatter strategy: opinionated vs. configurable. Pinte exists to loosen Laravel Pint's opinionated ruleset while keeping its ergonomics. This package is the decision artifact for "do we standardize on Pint, layer custom rules on PHP-CS-Fixer, or adopt a configurable wrapper?" — not a runtime dependency worth betting on.
• Build vs. buy vs. fork for developer tooling. Given it's archived, the realistic decision it informs is whether to fork a tiny formatter wrapper in-house versus adopting one. The answer is usually a thin, owned config file over PHP-CS-Fixer or Pint.
• Rollout and migration cost of style enforcement. A less-opinionated formatter is most useful where Pint's defaults would generate enormous one-time diffs on legacy code. This package is evidence for sequencing style adoption (per-directory rules, phased enforcement) rather than a blanket reformat.
• CI and pre-commit standardization. Whether style checks live in pipelines and hooks, and how permissive the gate should be. A configurable formatter reduces "developer fights the linter" friction — a real DX and retention consideration.
• Monorepo and multi-team governance. If separate teams want separate rules, a per-path configuration model is the product requirement; Pinte is a reference for that pattern, not an implementation to ship.
• Roadmap signal for internal platform teams. Low adoption (12 stars) despite a clear gap suggests the "configurable Pint" niche is either small or already served by PHP-CS-Fixer/Easy Coding Standard. Useful input before investing in a bespoke formatter.

When to Consider This Package

Consider it only as a reference implementation or a candidate for a vendored fork, and only when all of the following hold:

• You have a substantial legacy PHP/Laravel codebase where Pint's defaults produce disruptive, cross-cutting diffs.
• You need per-directory or per-team rule sets that Pint does not expose cleanly.
• You have a named owner on the engineering side willing to maintain a fork indefinitely.
• You are on a PHP/Laravel version compatible with the 2023-era dependency set and can pin transitive versions.

Look elsewhere — in practice, almost always — when:

• The project is greenfield or short-lived. Use Laravel Pint as-is; opinionation is a feature there.
• This is a long-lived production service. It is archived, unmaintained since June 2023, has 12 stars, and has no security or PHP-version support path. That is an unacceptable supply-chain position for tooling that runs in CI on every commit.
• You are in a regulated or audited environment requiring maintained dependencies and provenance.
• You want configurability without owning a fork. Use friendsofphp/php-cs-fixer directly with a checked-in config, or symplify/easy-coding-standard for a higher-level, actively maintained rule engine; both give configurability with real maintenance.
• You need PHP 8.3/8.4 or future Laravel support. No upgrade path exists.

Treat adoption as a fork decision with a maintenance budget, not a Composer dependency decision.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed developer tool that makes PHP code formatting more configurable than Laravel's default formatter. It has been archived by its author, has negligible adoption, and has had no releases since mid-2023. Recommendation: do not adopt it as a dependency. Its strategic value is as a design reference — it confirms demand for configurable formatting, which we can meet with a maintained alternative at effectively zero cost.

For engineering: Do not add jetstreamlabs/pinte to composer.json. If our team genuinely needs non-default rules, the low-risk paths are (a) Laravel Pint with a narrow custom rule set, (b) a checked-in PHP-CS-Fixer config we own, or (c) Easy Coding Standard. All three are maintained, auditable, and require no fork. Pinte is worth 30 minutes of reading to understand how a configurable layer is structured, then worth closing.

Bottom line: low evaluation value, high dependency risk. Standardize on a maintained formatter, keep the style config in-repo, and revisit only if Pint/Fixer prove genuinely insufficient — in which case budget for an owned fork rather than adopting an archived package.