Codingstyle Laravel Package

Product Decisions This Supports

• Build vs. buy for code-style enforcement. v1.0.5 is an infrastructure release: it adds m6web/coke to require, moves the squizlabs/php_codesniffer requirement out of core, and unlocks the m6web/symfony2-coding-standard constraint. Read together, these tell you the package is positioning itself as a distributable ruleset you install rather than a set of sniffs you fork. That supports a "buy" decision: adopt the ruleset, don't hand-maintain a phpcs.xml of 60+ sniffs.
• Adoption risk / dependency-conflict triage. The unlocked symfony2-coding-standard constraint and the relocated PHPCS requirement are both conflict-reduction moves. If your team previously hit Composer resolution failures pinning this alongside a newer PHPCS or Symfony standard, this release is the one that likely unblocks install. That's a concrete "can we ship this sprint" answer, not a roadmap item.
• CI quality-gate scope. Excluding Squiz.Strings.ConcatenationSpacing is a noise-reduction decision made for you — it's a sniff that generates churn on string concatenation spacing without catching defects. Use this as a signal when scoping your pipeline: this ruleset optimizes for low-false-positive style checks, so expect fewer "fix spacing" review comments and near-zero defect detection from it.
• Onboarding and review-cost reduction. The primary PM-visible outcome of any coding-standard package is fewer style debates in code review. Frame success metrics accordingly: PR review turnaround, count of style-only review comments, time-to-first-merged-PR for new hires.
• Not a fit for a Laravel-first roadmap. Nothing in this release (or the package's surface) indicates Laravel conventions. For a Laravel codebase, Laravel Pint is the lower-friction default and ships first-party. Treat this package as relevant only if you have Symfony-lineage code or an existing PHPCS-based pipeline you don't want to migrate.

When to Consider This Package

Adopt when:

• You already run PHP_CodeSniffer in CI and want a maintained ruleset instead of a bespoke phpcs.xml — the v1.0.5 dependency cleanup makes installation less likely to conflict with your existing toolchain.
• Your codebase has Symfony 2-lineage conventions (this ruleset descends from m6web/symfony2-coding-standard) and you want consistency without authoring sniffs.
• You need cross-framework style consistency across a polyglot PHP estate and are standardizing on PHPCS as the common substrate.
• You're on older PHPCS and were previously blocked by the pinned constraint — the unlock is the specific reason to re-evaluate now.

Look elsewhere when:

• The project is Laravel-first. Use Pint (zero-config, first-party, Prettier-style ergonomics) and save the PM/eng time entirely.
• You need static analysis or type safety, not style. This package does not address PHPStan/Psalm/larastan — those are a separate and higher-value purchase/decision.
• Maintenance confidence is a gating criterion. This is a vendor-owned (m6web) ruleset at v1.0.5 with a small release cadence. Before adopting, check commit recency, open-issue volume, and whether the ruleset tracks current PHPCS major versions. A coding standard that lags PHPCS majors becomes a source of dependency conflicts rather than a cure.
• You want autofix as the primary workflow. PHPCS autofixing is partial; Pint/php-cs-fixer are stronger here.

Upgrade risk for existing users: low. No breaking changes, no removals, no deprecations in v1.0.5 — it is a compatibility and hygiene patch. The one behavioral change is the Squiz.Strings.ConcatenationSpacing exclusion, which will cause previously-failing concatenation-spacing violations to stop being reported. If you have a baseline file or an ignore list referencing that sniff, prune it, or you'll carry dead config.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk developer-productivity tool, not a product feature. It automates code-style enforcement so engineers stop spending review cycles on formatting. Latest release (v1.0.5) is pure maintenance — dependency cleanups and one noisy-rule removal — which is a positive signal that the maintainers are keeping it installable, but it is not a reason to prioritize adoption on its own. Recommendation: only pursue if we already run PHPCS; otherwise standardize on Laravel Pint for near-identical benefit with less integration work. No budget, no headcount, no customer-facing impact.

To engineering: v1.0.5 loosens the m6web/symfony2-coding-standard constraint, relocates the squizlabs/php_codesniffer dependency out of core, adds m6web/coke to require, and excludes Squiz.Strings.ConcatenationSpacing. Net effect: fewer Composer resolution conflicts, less false-positive noise, no breaking changes — safe to bump. Two asks before we commit: (1) confirm the ruleset supports our current PHPCS major and PHP version, since an out-of-date standard reintroduces the exact dependency pinning this release removed; (2) if we're a Laravel shop, compare against Pint first — Pint covers the same ground with autofix and first-party support, and this package carries single-vendor maintenance risk plus Symfony 2-era conventions we'd be inheriting.

Confidence note: This assessment is derived from a single patch-release changelog; no license, download, issue-tracker, or PHPCS-version-compatibility data was available. Validate maintenance activity and PHPCS-major support before treating the "adopt" criteria as met.