Laravel Fmt Laravel Package

Technical Evaluation

What this actually is. The repository ships a Prettier-style code formatter for Laravel codebases — PHP, Blade, and (as of 0.3.0) PHP/Blade/HTML/CSS/JSON/YAML/XML fenced blocks inside Markdown — exposed as an Artisan command with a namespaced config. The package description on the listing ("render common values consistently… formatting rules instead of scattering ad-hoc PHP calls") describes a presentation-value helper library, not a code formatter, and does not match the release notes, the config keys (php.notOperatorSpace, markdown.proseWrap), or the CLI surface (--check, --reporter). Evaluate from the repo and changelog, not the marketing copy. That mismatch is a discovery-friction and trust signal, and it should be corrected in any internal write-up before a stakeholder reads the listing themselves and forms a different view of the cost.

Architecture fit. Good, and deliberately shallow: Laravel-native service provider, auto-discovery, facade, Blade helpers, published config. As a require --dev dependency it does not enter the runtime request path, so it cannot affect application latency, autoload weight in production, or upgrade compatibility of your Laravel version in the way a runtime package would. The architectural question it does touch is CI topology — it proposes collapsing Pint (PHP) + Prettier and prettier-plugin-blade (Blade/CSS/JSON/YAML) + manual Markdown discipline into one binary, one committed config, one CI step. That is a genuine reduction in moving parts, and it is the only reason to look at this package: Pint already solves PHP formatting and is Laravel-official. If PHP is your only pain, stop here.

Integration feasibility. Mechanically trivial — install pinned, publish config, commit it, run --check. The real cost is not installation, it is the reformat itself and the review capacity to absorb it. Feasible in a sprint as a spike; not feasible as a same-sprint "we now have a formatter" announcement.

Technical risk.

• Beta status is the headline risk, not a footnote. The package warns against production use. 0.3.0's changelog is overwhelmingly behaviour fixes — comment deletion in Blade @php and <?php ?> blocks, broken parsing of "{$a->f("x")}", layout shifting on a second run. Good sign for a beta; also a direct statement that 0.3.1 will change output on files you already formatted. Pin an exact version; treat upgrades as scheduled work, not composer update collateral.
• Idempotency is the gating property. Non-idempotent formatting is disqualifying for format-on-save and pre-commit hooks because it manufactures churn diffs and re-triggers hooks. The 0.3.0 notes read like a bug-fix campaign against exactly this class, but that is a claim about their tests, not your templates. Verification on your own representative sample is a required gate, not a nice-to-have.
• GitLab-only reviewer integration. --reporter gitlab --check emits a Code Quality report so violations annotate the MR diff. For GitHub Actions, Bitbucket, Jenkins or Azure DevOps shops this is a non-event — the single strongest capability in the release does not apply, and the adoption case degrades to "report-only log output," which is much weaker. Establish your SCM platform before scoping anything.
• Adoption risk, not capability risk. 13 stars, zero dependents, MIT, single-maintainer. No third-party production evidence, no ecosystem. Failure here is far more likely to be "nobody looked at the CI job" than "the formatter was wrong."
• Data hygiene. The recorded last release date (2026-11-03) is anomalous; confirm the actual release and pinned version against Packagist before writing it into a plan of record.

Key questions to close before committing budget.

1. Which SCM are we on, and does the GitLab reporter actually apply to us?
2. Does the tool support a --stdin / staged-paths mode, and is there any editor or format-on-save integration story? Without it, local ergonomics stay at composer fmt and hook viability drops.
3. What is the runtime on our largest tree, and can it be scoped to paths? CI cost matters at estate scale.
4. What is the maintainer's stated path to 1.0, and is there a published stability or config-freeze commitment?
5. Do we need an exit plan — i.e., is the config portable enough that reverting to Pint + Prettier is a config change rather than a re-architecture?
6. Is there a contribution path we would actually use, or is this strictly consume-only?

Integration Approach

Stack fit. Strong for a Laravel monolith or multi-repo estate where PHP, Blade and front-end assets are colocated and currently carry separate Pint and Prettier configs plus separate CI steps. Weak fit if you are PHP-only (use Pint), GitLab-only is a prerequisite for the reviewer benefit, and absent entirely if your team has no appetite for a repo-wide reformat this quarter.

Migration path. Deliberately incremental and reversible:

1. Add as dev dependency, pinned to an exact version — composer require --dev jacobjoergensen/laravel-fmt:0.3.0. No caret range during beta.
2. Publish and commit the config. Do not run on defaults — defaults are the thing most likely to move between beta minors, and an uncommitted config makes every CI run a different experiment.
3. php artisan fmt --check across the whole repo without writing. This produces the number that decides everything: how much of the codebase disagrees. On a mature app it will be large, and that number is the deliverable of step one.
4. Scope the first real run to directories you own — resources/views/components, app/Http/Controllers. Blade is the best day-one win because almost nobody hand-formats Blade consistently, so the diff is the most obviously correct one you will get.
5. Land the reformat as a commit containing nothing but formatter output, added to .git-blame-ignore-revs. Reviewers skip it; revert is one command; git blame survives.
6. Only after the tree is clean: pre-commit hook on staged paths, then blocking CI gate as backstop.

Compatibility.

• Config is namespaced per language (php.*, markdown.*, and equivalents), so a single committed file governs PHP, Blade, Markdown and asset formatting consistently. Use that: php.notOperatorSpace also governs Blade echoes and Alpine ! spacing, so set it once globally rather than per file type.
• Markdown formatting is safe to point at docs/ and README.md because a fenced block that fails to parse is preserved exactly as written. Pseudo-code, // ... elisions and intentionally broken examples survive — no blocklist to maintain.
• Exclude generated or vendor-published paths rather than chasing them: some byte sequences (form feed, vertical tab between PHP tokens) are deliberately rejected because PHP itself rejects them, so --check will flag those files forever.
• Upgrades cause churn even where prior output was "acceptable." Always split the dependency bump and the resulting reformat into two commits, or reviewers cannot separate the formatter's behaviour change from your code change.

Sequencing against the delivery calendar. This is a spike candidate, not a dependency. Do not attach it to a feature milestone.

The order is not optional. A hook installed before the repo is clean fights every commit and gets disabled inside a week — and a disabled hook is worse than no hook because it looks like enforcement on paper.

Operational Impact

Maintenance. Low in steady state, spiky at upgrade. The package is a dev dependency; there is no server to patch, no migration, no runtime surface. The recurring cost is the upgrade-and-reformat ritual: bump version on a branch, run formatter twice, assert git diff is empty, then land bump and reformat separately. Budget a half-day per minor release, and do not fold it into unrelated work. Also budget the config file as a reviewed artifact — it is the actual policy document, and changes to it should go through code review like any other behavioural change.

Support and bus factor. Single maintainer, 13 stars, zero dependents, MIT. There is no vendor, no SLA, no community to escalate to. Mitigations: pin exactly, keep the reformat commits isolated so an abandon-and-revert is a one-day operation, and record the fallback (Pint + Prettier + prettier-plugin-blade) in the decision log at the time of adoption — not after it becomes necessary. Do not build in-house: a Blade-aware formatter is multi-quarter work with a permanent tail (Blade evolves; the Alpine ! spacing rule and the unquoted-attribute <?= ?> parsing bug in this very release are the kind of long-tail parse defects you would be signing up to own forever). Formatting is not a differentiator; borrow, contribute upstream if the maintainer is responsive, and spend engineering budget on the roadmap.

Scaling. Two dimensions.

• Repo scale: run cost on a large monorepo is unmeasured — establish it in phase 0 before committing to a blocking gate, because a slow formatter in a blocking gate converts every merge into a queue. Scoped path runs mitigate this.
• Estate scale: the value proposition increases with the number of Laravel repos, because one config and one CI step replaces a stitched pipeline per repo. But each repo needs its own phase 0–4. Treat it as a rollout programme with a template, not a one-off task, and expect the second repo to be cheap and the fifth to be nearly free — the first is where all the learning cost sits.

Failure modes and detection.

Ramp-up. Cheap for developers, expensive for reviewers.

• Developers: one command. Put it in composer.json scripts as fmt and fmt:check so it is boring and discoverable; document it in the PR template, not a wiki page.
• Reviewers: the one-time cost. The reformat MR is where reviewer trust is won or lost. Isolated commit + .git-blame-ignore-revs + a two-line MR description ("formatter output only, no logic change") is the difference between a smooth rollout and a week of archaeology. Without it you poison git blame for months and pay the cost again in every subsequent review.
• Docs: the Markdown capability is worth a deliberate plug — pointing the formatter at README.md, docs/ and PR templates removes the recurring "this snippet no longer matches the API" review comment, and the parse-failure-preserves-input behaviour means no blocklist maintenance. Low effort, visible developer-experience win, and a good early proof point for stakeholders.

Bottom line for the decision record. Fund a scoped spike, not an adoption. Success criteria: repo-wide mismatch count measured, idempotency verified on our own Blade templates, GitLab (or not) applicability confirmed, and two weeks of MR data showing the signal is consumed. Revisit consolidation at 1.0. The realistic upside is retiring one config and one CI step per Laravel repo and getting Blade and Markdown coverage as a side effect; the realistic downside is a beta tool that reformats files on a patch bump, which is why the pin, the isolated commit, and the documented fallback are the whole risk posture.