Code Style Pint Laravel Package

Product Decisions This Supports

• Standardize-or-not decision for PHP style tooling across a Laravel portfolio. This package is the "last mile" of a standards strategy: if the team has already committed to artisanpack-ui/code-style as the canonical rulebook (PHPCS), this preset gives the auto-fix half so engineers don't hand-format to match the linter. That directly reduces PR review churn, "nit" comments, and merge latency.
• Build vs. buy vs. adopt-small-OSS on developer tooling. It answers a recurring build question cheaply: rather than writing and maintaining an in-house pint.json (and re-deriving it every Pint upgrade), the team adopts a versioned, published config with a documented rule mapping (docs/rules-mapping.md). The existence of a rules-mapping doc is the strongest signal here — it is the artifact that turns "style opinions" into a reviewable, defensible spec.
• Monorepo vs. per-package configuration strategy. PintConfigBuilder exists specifically for the case that matters at scale: Laravel packages have no php artisan, so a fluent builder plus a stub file lets a large package family share one generated config instead of N drifting copies. This is the single most product-relevant capability in the repo — it is infrastructure for consistency, not just formatting.
• Onboarding and contribution velocity roadmap item. New contributors inherit the standard by running one command (php artisan artisanpack:publish-pint-config) rather than reading a style guide. If contributor ramp-up time is a stated OKR, this is a measurable lever.
• Ecosystem/plugin strategy. The Laravel Boost AI-guideline override (.ai/guidelines/laravel/pint.blade.php) is a forward-looking bet: it steers AI-generated code toward the house style at generation time rather than at review time. That is a roadmap-relevant investment in a direction the ecosystem is clearly moving.
• WordPress-interop decision. The --wordpress flag plus the PHP-CS-Fixer stub covers a real product fork: teams shipping WordPress-adjacent PHP alongside Laravel can hold one spacing convention instead of two. Worth explicitly deciding whether that's in scope — it doubles the toolchain (Pint and PHP-CS-Fixer) and therefore doubles the support surface.
• Non-decision it enables: this is require-dev only. It carries no runtime footprint, no production dependency, no upgrade coupling for shipped artifacts — so the "cost" side of the ledger is almost entirely maintenance attention, not architecture.

When to Consider This Package

Adopt it if:

• You are already using, or planning to use, artisanpack-ui/code-style (PHPCS). These two are designed as a pair — Pint auto-fixes formatting, PHPCS catches what Pint structurally cannot (security checks, naming conventions, line length). Adopting one without the other gets you half a standard and a confusing "why does the linter still complain" conversation.
• You maintain more than one Laravel app or package and are paying real cost for inconsistent style — the PintConfigBuilder + stub pattern is where the ROI lives.
• You want a documented, mapped rule set rather than a hand-rolled pint.json with tribal knowledge attached.
• You are investing in DX: IDE integration docs (PhpStorm, VS Code, Vim), CI/CD recipes (GitHub Actions, GitLab CI), and a migration guide are all present. That documentation maturity is unusual for a package of this size and is the main reason to prefer it over a copy-pasted config.
• You need the WordPress-style spacing option and are willing to run PHP-CS-Fixer alongside Pint.

Look elsewhere if:

• You are a single-repo team already content with Laravel Pint's default preset. Pint ships working defaults; adding a dependency to get a pint.json you could write in ten minutes is not a good trade unless you need the builder or the ecosystem parity.
• You are not in the ArtisanPack UI ecosystem. The preset encodes someone else's opinions — Yoda style, mandatory declare(strict_types=1), void_return, aligned assignments. If your team has not adopted those, you will spend your first sprint disabling rules (the docs are honest about this: removeRule('yoda_style'), withBestPracticeRules(false)), and you have taken on a dependency to get a config you will fork anyway.
• Your stack is not PHP/Laravel — nothing here transfers.
• You require a hard vendor-risk posture. Flag for due diligence: 0 stars, 0 dependents, a single package in a young family, and a release dated in the future relative to typical review cadence. That is not disqualifying for a dev-only formatter — worst case you copy the stub and move on — but it should be recorded as a known risk rather than discovered later.
• License ambiguity must be resolved before adoption. Package metadata declares MIT, while the README's License section states GPL-3.0-or-later. These are materially different obligations. Do not merge this into a commercial codebase until legal/engineering confirms which applies; treat MIT as unverified.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, developer-only configuration package that makes our PHP code formatting automatic instead of a matter of taste. It costs nothing at runtime, ships no code to production, and its value is measured in review time and onboarding time recovered — every "fix your spacing" comment on a pull request is a cost we currently pay repeatedly. It is a standardization purchase, not a capability purchase: it only pays off if we are serious about holding one code style across our Laravel apps and packages, in which case it is the cheapest possible way to enforce that. Recommend a low-commitment trial in one repository, with two conditions before wider rollout: legal confirms the license (metadata and README disagree), and engineering confirms the preset's opinions — Yoda comparisons and mandatory strict types — match what we actually want, since those are the rules teams most often strip out.

To engineering (summary): Dev-only Composer dependency; publish a pint.json via php artisan artisanpack:publish-pint-config in apps, or generate one with PintConfigBuilder in packages where artisan isn't available. Rules are grouped into formatting / code-structure / best-practice and can be toggled or individually added and removed, so partial adoption is supported. It is explicitly complementary to the PHPCS package, not a replacement — run pint to auto-fix, then phpcs for what Pint can't express. CI story is ./vendor/bin/pint --test (or php-cs-fixer fix --dry-run --diff if we take the WordPress spacing path); IDE integration is documented for PhpStorm and VS Code. Expect to disable yoda_style and possibly declare_strict_types on day one unless we consciously adopt them — decide that as a team, in writing, rather than letting it be re-litigated per pull request. Note the toolchain splits in two if we adopt WordPress spacing: two binaries, two configs, two CI steps. Also note adoption is currently near-zero upstream, so pin the version and expect to own the config regardless of what the maintainer does next.