Vipwpcs Laravel Package

Product Decisions This Supports

• Vendor/roadmap commitment assessment: Choosing WordPress VIP as your managed hosting platform (or evaluating whether to migrate onto it) is a platform decision with real lock-in costs. This ruleset is the machine-readable contract for "will our code survive VIP review," so it directly informs the build-vs-buy calculation: adopting VIP plus this package replaces a bespoke internal WP code-review checklist with a maintained, upstream one.
• Build vs. buy for code quality gates: Rather than writing and maintaining custom PHPCS sniffs for platform-specific restrictions (restricted functions, cache-incompatible queries, escaping rules, hook contracts), the team inherits Automattic's rules — 3.0.x and later track WordPressCS 3.1.0+, PHPCS 3.13.2+, and PHP 8.2/8.3 support. That's a "buy" (well, GPL-adopt) decision with an ongoing maintenance transfer of ownership to a third party.
• Platform-tier decision: The two rulesets (WordPressVIPMinimum for legacy WordPress.com VIP, WordPress-VIP-Go for VIP Go) map to two hosting products. The package makes the tier choice concrete: which ruleset you wire into CI is a direct signal of which platform your codebase targets, which matters when planning a WordPress.com VIP → VIP Go migration.
• Roadmap sequencing and blocker discovery: Running the ruleset against an existing codebase is effectively a technical-debt inventory. The volume of errors vs. warnings (the docs distinguish these) becomes a proxy for migration effort — a fast, cheap way to size platform migration work before committing to a date.
• Feature-level go/no-go: Some sniffs encode product-visible constraints (e.g., ORDER BY RAND(), posts_per_page => -1, post__not_in, suppress_filters). These surface as warnings/errors when a feature design assumes unbounded queries or uncached results. That's a decision input before code is written, not after.
• Developer experience / onboarding as a product concern: Composer-based install with the installer plugin bundled (since 2.3.0) means a new engineer or contractor gets an enforcing environment in two commands. Fewer review round-trips with the VIP team is an adoption-friction metric worth tracking.
• Use cases this supports: pre-commit/CI gating for VIP-hosted WordPress sites and plugins, agency delivery on VIP client work, plugin/theme vendors who need to declare VIP compatibility, and CI parity with VIP's own Code Analysis Bot so local results match platform review.

When to Consider This Package

Consider adoption when:

• You host on, or are contracted to deliver onto, WordPress VIP (either platform tier) — this is close to a hard requirement, not an optional lint.
• You want CI to reproduce VIP's automated review findings so failures are caught in the PR rather than in platform review.
• You already run PHPCS/WPCS and want the VIP delta layered on top of standard WordPress Coding Standards rather than replacing them.
• You need a repeatable, versioned definition of "VIP-ready" for external contributors, contractors, or acquired codebases.
• Your pipeline can satisfy the dependency chain — PHPCS 3.13.2+, PHPCSUtils 1.1.0+, PHPCSExtra 1.4.0+, WPCS 3.1.0+, VariableAnalysis 2.12.0+ — and you can grant the Composer plugin permission (allow-plugins.dealerdirect/phpcodesniffer-composer-installer) required on Composer 2.2+.

Look elsewhere when:

• You are not on WordPress VIP. The ruleset encodes VIP platform constraints (caching layer, restricted APIs); on generic WP hosting it will produce noise and false constraints, and WPCS alone is the better fit.
• You need a general-purpose PHP or WordPress style standard rather than a platform-compliance gate — use WPCS plus your house ruleset.
• Your team cannot accept the GPL-2.0-or-later license implications, or your org flags the NOASSERTION license metadata as an unresolved legal review item.
• You need guaranteed support SLAs or vendor accountability. This is community/automattic-maintained OSS with a small contributor base; there's no commercial support contract attached to the package itself.
• Your stack is not PHP or your WordPress footprint is headless/JS-dominant — coverage is PHP-only.
• You depend on sniffs that were removed (BatcacheWhitelistedParams, Zoninator, bundled VariableAnalysis sniff) or on error codes that were renamed in 3.0.0 — verify your baseline/ruleset config before upgrading, and expect to re-baseline suppressions.
• Adoption risk to weigh: Dependents: 0 in the supplied metadata and 261 stars indicate a niche audience; treat the ecosystem signal as "authoritative for its narrow purpose, thin everywhere else." Budget a spike to validate against your real codebase rather than assuming drop-in.

How to Pitch It (Stakeholders)

To executives: This is a free, Automattic-maintained linter that encodes the exact rules WordPress VIP enforces on our code. Adopting it moves compliance checking from platform review — where failures cost us release cycles — into our own CI, before code ships. It's a two-command Composer dev dependency, no runtime footprint, no license cost, and it transfers the maintenance burden of platform rules to the platform vendor. Decision framing: if VIP is our hosting direction, this is table stakes; and running it against our current code gives us a defensible estimate of migration effort before we commit to dates.

To engineering: automattic/vipwpcs gives you the WordPressVIPMinimum and WordPress-VIP-Go rulesets on top of WPCS, PHPCSUtils/PHPCSExtra, and VariableAnalysis. Install as a dev dependency, allow the Composer installer plugin, point PHPCS at the ruleset matching your platform tier, and gate CI on it. Two things to plan for: the dependency floor is current (PHPCS 3.13.2+, WPCS 3.1.0+, PHP 8.2/8.3 supported), and the 3.0.0 major renamed several error codes and dropped three sniffs — so expect to regenerate any suppression baseline and re-verify ignore comments. Start with a non-blocking report-only run, size the violation count against the errors/warnings distinction, then ratchet to blocking on changed files.