Laravel Fmt Laravel Package

Product Decisions This Supports

• Toolchain consolidation: one formatter for the whole Laravel repo, or a stitched pipeline. A typical Laravel repo today runs Pint for PHP, Prettier plus a Blade plugin for templates and assets, and relies on manual discipline for Markdown. This package's release notes show it covering PHP, Blade, HTML, CSS, JSON, YAML and XML — including fenced code blocks inside Markdown, and PHP snippets written without <?php. That moves "one binary, one config, one CI step" from aspiration to something you can actually evaluate on a branch this quarter, and gives you a concrete cost comparison against the status quo.
• Whether formatting violations surface in code review or in a build log. The --reporter gitlab flag paired with --check writes a GitLab Code Quality report, so unformatted files annotate the merge request diff rather than failing a job with an opaque log dump. This is the strongest single reason to look at the package now rather than at 1.0 — and it is GitLab-only, so it is a non-event for GitHub Actions, Bitbucket or Jenkins shops. Adoption friction, not raw capability, is what usually kills a formatter rollout.
• Sequencing a developer-experience / repo-hygiene epic. This is a spike candidate, not a dependency. A defensible sequence to approve: (1) non-blocking --check job in one repo, (2) measure diff noise and review-comment volume across two weeks of real MRs, (3) promote to a blocking gate only once idempotency holds on your codebase, (4) reassess at 1.0. Each step has a measurable exit criterion and a cheap reversal.
• Pre-commit hooks and format-on-save: viable yet, or not? A large share of the 0.3.0 changelog is idempotency work — binary operators, concatenations and destructuring assignments changing layout on a second run, a lone @ in Blade text shifting layout, method chains indented deeper after a multi-line operand, markdown.proseWrap: always re-wrapping lists and blockquotes. Non-idempotent formatters are disqualifying for write-on-save and commit hooks because they generate churn diffs and re-trigger hooks on every commit. This release is the first credible signal that hook-based adoption is on the table; it must be verified against your own templates before you fund the work.
• Build vs. buy. An in-house Blade-aware formatter is multi-quarter work with a permanent maintenance tail: Blade evolves, and the Alpine ! spacing rule and the <div x=<?= $a ?>> unquoted-attribute fix in this release are exactly the long-tail parse bugs you would be signing up to own forever. Formatting is not a product differentiator. Borrow, contribute upstream, and spend the engineering budget on the roadmap.
• Documentation-as-code investment. Formatting fenced blocks in README.md, docs/ and PR templates removes a recurring "this snippet no longer matches the API" review comment. Because a block that fails to parse is kept exactly as written, pseudo-code, // ... elisions and deliberately broken examples survive untouched — so pointing it at a docs directory needs no blocklist and carries near-zero blast radius.
• A positioning caveat to record in the evaluation. The package's description frames it as a lightweight utility for rendering values consistently — display formatting, not code formatting. The release notes and config keys (php.notOperatorSpace, markdown.proseWrap) describe the real product, which is a Prettier-style code formatter. For a PM this is a discovery-friction and trust signal: evaluate from the repository and changelog, and expect the top of the funnel to under-represent what the tool does. It also means you should confirm which product you're actually adopting before writing a ticket.

When to Consider This Package

Consider it when:

• You run a Laravel monolith or a multi-repo Laravel estate where PHP, Blade and front-end assets are all in scope, and you are maintaining separate Pint and Prettier configs plus separate CI steps.
• You are on GitLab and want formatting violations visible as MR annotations rather than a red pipeline — this is the feature that changes the adoption conversation most.
• Blade is your pain point. Almost nobody hand-formats Blade consistently, so it produces the most obviously correct diff you'll get on day one. resources/views/components is a good pilot scope.
• You have appetite for a pinned, deliberately upgraded dev dependency and can isolate "format everything" into its own commit (and .git-blame-ignore-revs).
• You can start report-only in CI and promote to blocking later. Teams that need a blocking gate on day one should wait.
• You want the docs win: Markdown fenced-block formatting that fails safe on unparseable snippets.

Look elsewhere when:

• You only need PHP formatting. Pint is mature, Laravel-official, already in your scaffolding and has an ecosystem. The entire reason to consider this package is Blade + Markdown coverage and the single-config story. PHP is a solved problem.
• You are not on GitLab. The 0.3.0 headline does nothing for GitHub Actions, Bitbucket or Jenkins. Stay in report-only mode and revisit.
• You need production-grade guarantees, an SLA, or a support contract. The package self-describes as beta and explicitly not recommended for production code. That warning is about churn risk, and it is honest.
• Ecosystem maturity is a hard requirement. Thirteen stars and zero dependents means no Stack Overflow corpus, no blog-post troubleshooting, no third-party plugins, and a real bus-factor question. Budget for "we will read the source and file issues upstream," not "we will Google the error."
• Your team cannot absorb a reformat churn event this quarter. Even where the old output was "right," comment-placement and string-interpolation fixes in 0.3.0 will rewrite previously formatted files. Land the version bump and the reformat as separate commits or reviewers can't separate behaviour change from code change.
• What you actually wanted was value/display formatting. If the description is why you clicked, this is not that product.

How to Pitch It (Stakeholders)

To executives — a small, reversible bet on engineering throughput. We currently pay a maintenance tax on three overlapping formatting setups (Pint, Prettier plus a Blade plugin, and manual Markdown discipline) and on review comments about snippet drift in docs. A single Laravel-native tool now covers PHP, Blade, Markdown and front-end assets from one config and one CI step, and it can surface violations directly on GitLab merge requests instead of in a failed job log. The proposal is not to adopt it as a dependency. It is one engineer for one sprint to run it read-only against one repo, measure the diff noise and review-comment impact, and return with a go/no-go. Cost is a dev dependency and a non-blocking CI job; downside is contained by pinning an exact version and keeping the reformat in a single revertible commit. The alternative — building this ourselves — is multi-quarter work with a permanent maintenance tail on Blade parser edge cases, for zero product differentiation.

To engineering — the pitch is "one config, one command, and you can bail at any point." Concretely: install pinned to an exact version, publish and commit the namespaced config so every developer and CI run makes identical decisions, and add composer fmt / composer fmt:check scripts. Start with --check on one directory you own — resources/views/components is the best first target because the diff is unambiguous — then run for real and read the git diff before letting it near anything else. In CI, --check --reporter gitlab annotates the MR; confirm the artifact filename on the first run rather than assuming it. The 0.3.0 release is largely a list of fixed idempotency bugs, which is exactly what you want to see in a beta and exactly what you should not take on faith: spend five minutes formatting a representative sample of our templates, running it a second time, and asserting git diff is empty. That single test gates whether hooks and format-on-save are on the table. Known rough edges to plan around: form feeds or vertical tabs between PHP tokens now fail rather than format, unquoted Blade attribute values holding PHP tags are inherently ambiguous (quote them), and comment handling at the end of @php / <?php ?> blocks has changed more than once — diff those files specifically after any upgrade. And if we only wanted PHP formatting, we'd stop here and keep Pint.

The ask: approve the spike (one engineer, one sprint, one repo, report-only CI), with a decision gate at two weeks or at the package's 1.0, whichever comes first.