Coding Standard Laravel Package

Product Decisions This Supports

• Consistency & Maintainability: Enforces ShipMonk’s internal PHP/Laravel coding standards (e.g., naming conventions, PSR compliance, custom rules) to reduce technical debt and onboarding friction for new engineers.
• Developer Experience (DX): Standardizes linting/autofix workflows, reducing manual review cycles and enabling CI/CD integration (e.g., pre-commit hooks, GitHub Actions).
• Build vs. Buy: Justifies not reinventing a custom ruleset (saves engineering time) while aligning with ShipMonk’s ecosystem (vs. generic tools like slevomat/coding-standard).
• Roadmap Enablers:
  • Scaling Teams: Critical for distributed teams or open-source contributions to ShipMonk’s packages.
  • Laravel Monorepos: Ensures uniformity across microservices or shared libraries.
  • Security/Compliance: Aligns with audits by enforcing ShipMonk’s internal best practices (e.g., dependency management, error handling).

When to Consider This Package

• Adopt if:
  • Your team is heavily invested in ShipMonk’s ecosystem (e.g., using ShipMonk’s Laravel packages, contributing to their open-source projects).
  • You need ShipMonk-specific rules (e.g., custom Laravel conventions, internal security patterns) that aren’t covered by slevomat/coding-standard or PSR-12.
  • You’re standardizing a new PHP/Laravel codebase and want to avoid context-switching between multiple rulesets.
• Look elsewhere if:
  • Your project is not tied to ShipMonk’s stack (use slevomat/coding-standard or phpcs defaults instead).
  • You require enterprise-grade customization (this package is lightweight; consider PHP_CodeSniffer plugins or psalm for advanced static analysis).
  • Your team lacks PHP/CS tooling maturity (start with PSR-12 or rector for incremental adoption).

How to Pitch It (Stakeholders)

For Executives: "This package lets us enforce ShipMonk’s proven PHP/Laravel coding standards with minimal overhead—no reinventing the wheel. It’s like a ‘style guide’ for our codebase, reducing bugs and speeding up reviews. For example, it’ll catch inconsistencies in how we handle Laravel’s dependency injection or error logging, which saves time in production. It’s a low-cost way to future-proof our code quality as we scale."

For Engineering: *"This is ShipMonk’s battle-tested phpcs ruleset, tailored for their Laravel packages. It’s a drop-in replacement for slevomat/coding-standard but with ShipMonk-specific tweaks (e.g., how they structure service containers or handle API responses). We can:

• Enforce consistency across all PHP/Laravel projects with a single config.
• Autofix common issues in CI (e.g., trailing whitespace, missing docblocks) to avoid manual PR comments.
• Integrate with our existing toolchain (e.g., run it in GitHub Actions or pre-commit hooks). It’s MIT-licensed, so no legal risks, and the setup is trivial—just add it to composer.json and configure phpcs.xml.dist."*

For Developers: *"Think of this as ‘ShipMonk’s way’ of writing PHP/Laravel code, automated. It’ll flag things like:

• Inconsistent method naming (e.g., getUser() vs fetchUser()).
• Missing type hints in Laravel controllers.
• Custom ShipMonk patterns (e.g., how they structure Eloquent models). Run vendor/bin/phpcs locally before pushing, and it’ll catch 80% of ‘nitpicks’ your PR reviewer would otherwise mention. The phpcbf command even auto-fixes some issues!"*