Coke Laravel Package

Technical Evaluation

Architecture Fit

• Limited Modern Fit: The package (m6web/coke) is a deprecated PHP Code Sniffer configurator (last updated in 2017), designed for legacy PHP projects. It does not align with modern Laravel (v10+) or contemporary PHP (8.1+) architectures, which rely on:
  • Composer-based autoloading (PSR-4) vs. older include_path configurations.
  • Built-in tools (e.g., php-cs-fixer, Laravel’s phpunit.xml presets) for static analysis.
  • Decoupled tooling (e.g., GitHub Actions, PHPStan) over monolithic configurators.
• Niche Use Case: Only relevant if maintaining a pre-Laravel 5.x codebase or enforcing obsolete coding standards (e.g., legacy PSR-0, custom rules from 2017).

Integration Feasibility

• High Risk: Direct integration is not recommended due to:
  • Breaking Changes: Laravel’s dependency graph (e.g., Symfony components, modern PHP) will conflict with this package’s assumptions.
  • Toolchain Obsolescence: Code Sniffer itself is superseded by php-cs-fixer (active maintenance) and PHPStan.
  • No Laravel-Specific Features: Lacks integration with Laravel’s service container, Artisan commands, or testing utilities.
• Workarounds:
  • Static Analysis: Replace with php-cs-fixer + custom rules (via config/cs.php).
  • Legacy Compatibility: Isolate in a separate Docker container or CI step (e.g., GitHub Actions) for backward compatibility checks.

Technical Risk

Key Questions

1. Why Deprecated?

   • Is the package being used for specific legacy rules not covered by php-cs-fixer?
   • Are there custom Code Sniffer standards (e.g., in-house PSR extensions) that must be preserved?

2. Alternatives Evaluated

   • Has php-cs-fixer + php-cs-fixer-config been tested as a drop-in replacement?
   • Are there Laravel-specific static analysis tools (e.g., laravel-pint, pestphp/pest) that could replace this?

3. Migration Path

   • What’s the minimum viable compliance for the team? Can rules be extracted and reimplemented in php-cs-fixer?
   • Is there a legacy codebase that must use this tool, or is it a historical artifact?

4. Team Skills

   • Does the team have Code Sniffer expertise to debug integration issues, or would this block velocity?

Integration Approach

Stack Fit

• Incompatible with Modern Laravel:
  • PHP Version: Requires PHP ≤7.1 (Laravel 10+ needs PHP 8.1+).
  • Composer: Assumes older composer.json structures (no autoload-dev for tools).
  • Tooling Ecosystem: No support for Laravel’s Pint, Pest, or Forge-based deployments.
• Potential Stacks Where It Might Fit:
  • Legacy Monoliths: Pre-Laravel 5.x applications with no migration timeline.
  • Custom CI Pipelines: As a one-off step in a hybrid CI (e.g., "Run Coke if legacy-branch is targeted").

Migration Path

1. Assessment Phase:

   • Run composer why m6web/coke to identify direct/indirect dependencies.
   • Extract custom rules (if any) from Coke/Config.php and port to php-cs-fixer (e.g., via --rules config).

2. Phased Replacement:

   • Short-Term: Wrap the package in a custom Artisan command to isolate it (e.g., php artisan coke:check).
   • Medium-Term: Replace with php-cs-fixer + custom rules (example config below).

     # php-cs-fixer.config.php
     return PhpCsFixer\Config::create()
         ->setRules([
             '@PSR12' => true,
             'concat_space' => ['spacing' => 'one'], // Example: Mimic Coke's rules
         ]);
     

   • Long-Term: Deprecate the package entirely; archive rules in a LEGACY_RULES.md file.

3. Fallback Strategy:

   • Containerize the package in a Docker image with PHP 7.1 + legacy dependencies.
   • Example Dockerfile:

     FROM composer:7.1
     RUN composer require m6web/coke:dev-master
     COPY . /app
     WORKDIR /app
     CMD ["vendor/bin/phpcs", "--standard=Coke/Config", "--report=full"]
     

Compatibility

Sequencing

1. Audit: Identify all files/rules using m6web/coke.
2. Isolate: Create a legacy branch with the package pinned.
3. Replace: Migrate rules to php-cs-fixer incrementally (e.g., one rule per sprint).
4. Deprecate: Remove the package after 6–12 months (or when all rules are migrated).

Operational Impact

Maintenance

• High Overhead:
  • No Updates: MIT license but abandoned (last release 5 years ago).
  • Dependency Rot: Risk of broken transitive dependencies (e.g., old PHPUnit, Symfony components).
  • Rule Drift: Custom rules may no longer reflect team conventions.
• Mitigation:
  • Fork the Package: Maintain a private fork with critical fixes.
  • Automate Rule Extraction: Use a script to export rules to php-cs-fixer format.

Support

• Limited Resources:
  • No Community: 68 stars but no recent issues/PRs.
  • Debugging Complexity: Stack traces will reference obsolete PHP versions and Composer setups.
• Support Plan:
  • Tier 1: Document known issues (e.g., "Fails on PHP 8.0+").
  • Tier 2: Provide a Docker-based sandbox for legacy checks.
  • Tier 3: Offer a migration service to php-cs-fixer.

Scaling

• Performance:
  • Slow Execution: Code Sniffer is less optimized than php-cs-fixer.
  • Memory Usage: May struggle with large codebases (e.g., >1M LOC).
• Scaling Strategies:
  • Parallelize: Run in CI as a separate job with resource limits.
  • Cache Results: Store outputs in artifact storage (e.g., GitHub Actions cache).

Failure Modes

Ramp-Up

• Onboarding Cost:
  • High: Requires understanding