Code Sniffer Laravel Package

Technical Evaluation

Architecture Fit

• PSR-2/PSR-12 Compliance: The package enforces strict adherence to PSR coding standards, which aligns well with Laravel’s PHP-centric ecosystem. Laravel already follows PSR standards, so this package would reinforce consistency without disrupting existing patterns.
• Extensibility: The package allows customization via ruleset.xml, enabling TPMs to tailor rules to project-specific needs (e.g., excluding legacy code or adding custom sniffs). This is critical for Laravel projects with legacy modules or third-party integrations.
• Spryker-Specific Rules: While Spryker’s sniffs (e.g., Spryker.Namespaces.SprykerNamespace, Spryker.MethodAnnotation.*) are Spryker-centric, many are generic enough (e.g., namespace validation, method annotation checks) to be repurposed for Laravel’s service container, repositories, or facade patterns.
• Strict Mode Support: The ability to enforce declare(strict_types=1) aligns with Laravel’s modern PHP practices (PHP 8.0+).

Key Fit Areas:

• Laravel’s service container (e.g., validating dependency injection annotations).
• Repository/Service Layer (e.g., enforcing consistent method signatures for Eloquent models or custom repositories).
• Facade Patterns (e.g., ensuring annotations match Laravel’s Facade conventions).
• CI/CD Integration (e.g., pre-commit hooks or GitHub Actions for automated linting).

Misalignment Risks:

• Spryker-specific sniffs (e.g., Spryker.Eco, SprykerSdk) may require customization or exclusion for Laravel projects.
• Laravel’s Blade templates or Artisan commands may need custom exclusions in ruleset.xml.

Integration Feasibility

• Composer Integration: The package is require-dev-friendly, with zero runtime dependencies, making it easy to adopt without affecting production.
• CLI/Console Compatibility: The console code:sniff:style command integrates seamlessly with Laravel’s Artisan CLI, reducing friction for developers accustomed to php artisan.
• IDE Support: Pre-configured PHPStorm/VSCode setups (via phpcs/phpcbf) can be adapted for Laravel projects with minimal effort.
• Laravel-Specific Customizations:
  • Exclude vendor/, bootstrap/, and storage/ directories by default.
  • Add Laravel-specific sniffs (e.g., validating Illuminate\Contracts usage, checking app/Providers for service binding consistency).
  • Override Spryker’s namespace rules to match Laravel’s App\, Database\, or Http\Controllers conventions.

Example Customization:

<!-- In custom ruleset.xml -->
<rule ref="vendor/spryker/code-sniffer/Spryker/ruleset.xml">
    <exclude-pattern>vendor/</exclude-pattern>
    <exclude-pattern>bootstrap/</exclude-pattern>
    <exclude-pattern>storage/</exclude-pattern>
    <exclude name="Spryker.Namespaces.SprykerNamespace"/> <!-- Disable Spryker-specific namespace checks -->
</rule>

Technical Risk

Key Questions for TPM

1. Adoption Scope:

   • Should this replace existing tools (e.g., php-cs-fixer, laravel-pint) or run alongside them?
   • Which Laravel-specific rules are critical to enforce (e.g., service container annotations, Blade syntax)?

2. Customization Needs:

   • Are there Laravel modules/packages that should be excluded from sniffs?
   • Should the SprykerStrict standard be used, or is Spryker sufficient?

3. CI/CD Integration:

   • How should failures be handled (e.g., block PRs, warn only)?
   • Should sniffs run in parallel with other tests or in a separate stage?

4. Developer Experience:

   • Should the package provide a Laravel-specific Artisan command (e.g., php artisan code:sniff)?
   • How will IDE integration be communicated to the team?

5. Long-Term Viability:

   • Is Spryker’s maintenance of this package reliable, or should a fork be created for Laravel-specific needs?
   • Should the package be deprecated in favor of Laravel’s native tools (e.g., pint)?

Integration Approach

Stack Fit

• Laravel Ecosystem:

  • PHP 8.2+: Aligns with Laravel 10+/11’s requirements.
  • Artisan CLI: The console code:sniff:style command maps cleanly to Laravel’s php artisan workflow.
  • Service Container: Sniffs for dependency injection annotations (e.g., @inject) can validate Laravel’s bind()/singleton() usage.
  • Testing: Integrates with Laravel’s testing tools (e.g., run sniffs in phpunit.xml as a listener).

• Tooling Compatibility:

  • PHP_CodeSniffer: The underlying tool is battle-tested and widely used in PHP projects.
  • PHPStan/Psalm: Can complement static analysis by adding type-checking layers.
  • Git Hooks: Pre-commit hooks can run phpcbf to auto-fix issues.

• IDE/Editor Support:

  • PHPStorm/VSCode: Pre-configured sniffs can be added via external tools or file watchers.
  • Laravel IDE Helpers: Ensure sniffs don’t conflict with IDE-generated files (e.g., app/Models/HasFactory.php).

Migration Path

1. Pilot Phase:

   • Install in a non-production environment (e.g., feature branch).
   • Run sniffs on new code only (exclude app/ except app/Http/ and app/Providers/).
   • Customize ruleset.xml to match Laravel conventions (e.g., namespace rules, Blade exclusions).

2. Gradual Rollout:

   • Phase 1: Enforce sniffs in CI for new PRs only.
   • Phase 2: Add to pre-commit hooks for developers.
   • Phase 3: Expand to legacy codebases with opt-in fixes (e.g., phpcbf --diff).

3. Tool Replacement:

   • Replace php-cs-fixer or pint if this package offers superior Laravel-specific rules.
   • Deprecate custom sniffs in favor of this package’s standards.

Compatibility

Sequencing

1. Pre-Integration:

   • Audit existing codebase for violations (run phpcs with --report=full).
   • Document known issues and plan fixes (e.g., bulk phpcbf for auto-fixable errors).

2. Integration:

   • Add to composer.json as require-dev.
   • Configure DevelopmentConfig.php (or Laravel’s equivalent) to point to the custom ruleset.xml.
   • Set up CI pipeline (e.g., GitHub Actions) to run sniffs on PRs.

3. Post-Integration:

   • Train developers on using phpcbf and IDE integrations.
   • Monitor false positives and adjust rules as needed.
   • Schedule quarterly reviews to update sniffs (e.g., for new PHP features).

Operational Impact

Maintenance

• Rule Updates:
  • Subscribe to