Codestyler Laravel Package

Product Decisions This Supports

• Engineering standards as a product decision, not a per-repo debate. Codestyler turns "what code style do we use?" into a versioned, publishable artifact. It ships curated pint.json presets (PHP 8.2–8.5), a rector.php preset (laravel or default), .editorconfig, and biome.json, then standardizes the composer.json scripts that invoke them. For a PM, that is a repeatable policy lever across a portfolio of Laravel services rather than a style argument in every pull request.
• Onboarding and time-to-first-commit. A new Laravel repo gets linting, auto-fixing, IDE alignment, and frontend formatting by adding one dev dependency and a short post-update-cmd block. This directly reduces ramp-up cost for new hires and contractors and shortens the "make the repo conform" phase of migrations and acquisitions.
• Build vs. buy (and buy vs. assemble). The alternative is hand-rolling the same four config files and CI YAML per repo, or maintaining an internal preset package. Codestyler is a thin, MIT-licensed wrapper over tools the team likely already uses (Laravel Pint, Rector, Biome, Composer Normalize). It is cheap to adopt and cheap to abandon — the published files land in your repo, so there is no runtime coupling and no proprietary format. Prefer adopting it over building an internal equivalent unless you need custom rules that diverge materially from the presets.
• CI and governance roadmap. It pairs with a reusable GitHub Actions workflow (TheDragonCode/.github/.github/workflows/code-style.yml) toggling php and node, which makes "code style is enforced in CI" a config change rather than a platform project. That supports incremental rollout: publish configs first, add advisory CI, then make the check blocking.
• Diff hygiene and review throughput. Automated fixes plus composer normalize and JSON/JS formatting reduce noise in reviews and merge conflicts, which shows up as a measurable (if modest) cycle-time improvement. The 6.8.1 release reinforces this: the PHP migration rule sets behind each preset were trimmed of obsolete rules for older PHP versions, so upgrades should produce smaller, more targeted Rector diffs instead of re-touching legacy migrations.
• Upgrade sequencing is a preset decision. Because the Rector migration rules are bundled inside the versioned presets, "which modernizations do we auto-apply?" is governed by the package version rather than by local config. That is convenient, but it means the Rector behavior of an upgrade is set by the release you pin — plan dependency bumps for the Rector side of the toolchain deliberately, not as a background composer update.
• Use cases: standardizing a fleet of Laravel apps or packages; preparing a codebase for a PHP 8.4/8.5 upgrade via Rector; unifying PHP and JS/CSS/JSON style in full-stack Laravel repos; normalizing repos inherited through acquisition; giving agency or multi-client teams a consistent baseline.

When to Consider This Package

Adopt it when:

• You maintain more than one Laravel/PHP repository and want identical style configuration across them without copy-paste drift.
• Your team already accepts Laravel Pint and optionally Rector as the PHP toolchain, and Biome for JS/CSS/JSON.
• You want the config pinned to a version you control, with the option to review preset changes as a normal dependency diff. Note that preset contents do change between patch releases — 6.8.1 removed obsolete PHP migration rules from every pint/Rector ruleset — so treat preset diffs as reviewable behavior changes, not cosmetic noise.
• You value the low-lock-in property: the generated pint.json, .editorconfig, biome.json, and rector.php are plain files in your repo.
• You want a ready-made CI path via a reusable GitHub Actions workflow and are comfortable depending on the vendor's workflow repository.

Look elsewhere or build in-house when:

• Your standard is PHP_CodeSniffer / PHP-CS-Fixer with a custom ruleset, or you need rule-level governance and review that the presets don't expose.
• You are not on Laravel and want a neutral, framework-agnostic standards package.
• You need vendor support, SLAs, security review artifacts, or a broad adoption signal. This is a low-star, essentially single-maintainer package with zero listed dependents; treat it as a config source rather than infrastructure.
• Your frontend is not JS/JSON/CSS-adjacent (e.g., different formatter ecosystem), so the Biome half provides no value.
• You already have an internal platform team publishing shared configs; adding a second source of truth creates conflict.
• Your policy forbids new dev dependencies, or your composer update must remain side-effect-free — note the design copies and overwrites .editorconfig and related files on post-update-cmd, which can silently clobber local customization.
• You require stable, documented preset semantics across upgrades. The Rector rulesets are curated by the maintainer and revised in place; there is no changelog of individual rule changes beyond release notes like 6.8.1's "remove old PHP migration rules." If you need rule-by-rule control and auditability, own the rector.php yourself.

Risk posture: low blast radius (dev-only, files copied locally, MIT, easily removed) offset by low bus factor and mutable preset contents. Mitigation is to vendor the generated configs, pin the version, and review preset changes at upgrade time rather than auto-accepting them — 6.8.1 is a good example of a patch release that quietly changes what Rector will rewrite on your next run.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk developer-productivity lever. It standardizes code formatting and static fixes across our PHP/Laravel repositories by publishing a shared set of configuration files, so engineers stop re-litigating style and spend review time on logic. Cost is one dev-only dependency under a permissive MIT license; impact is faster onboarding, cleaner diffs, and a straightforward path to enforcing style in CI. Because the configuration is copied into our repos as plain files, we are not locked in — if the package stalls, we keep the files and drop the dependency.

For engineering: Add dragon-code/codestyler as a dev dependency, wire a few post-update-cmd calls to publish pint.json (PHP 8.2–8.5 presets), rector.php (laravel preset), .editorconfig, and biome.json, and expose a single composer style entry point running Rector and Pint. Frontend formatting uses Biome via npm. A reusable GitHub Actions workflow enables enforcement. Watch three things: the publish step overwrites existing config files (commit and review the diff); the Rector rulesets change between releases — 6.8.1 dropped legacy PHP migration rules across all four PHP presets, so a routine dependency bump can change the scope of automatic refactors; and the package is maintained by a single author with minimal adoption. Pin the version, keep the generated configs in version control, review preset diffs on upgrade rather than auto-accepting them, and be prepared to own the files. Recommended rollout: pilot on one service, compare the resulting diff volume, then apply to new repos by default and retrofit existing ones during planned upgrade work.