Tlint Laravel Package

Product Decisions This Supports

• Enforce Laravel Coding Standards: Adopt tightenco/tlint to standardize codebase conventions (e.g., facades, Blade directives, class visibility, and request validation) across teams, reducing onboarding friction and technical debt.
• Automate Code Quality Gates: Integrate into CI/CD pipelines (e.g., GitHub Actions) to block non-compliant PRs, ensuring consistency before merge. Example: Fail builds if NoDump (e.g., dd(), ray()) or NoRequestAll violations exist.
• Modernize Legacy Code: Use formatters (e.g., FullyQualifiedFacades, AnonymousMigrations) to batch-update codebases to align with Laravel 8+ best practices, reducing manual refactoring effort.
• Customize Team-Specific Rules: Extend presets (e.g., Tighten or Laravel) to enforce project-specific rules (e.g., disallow Auth::user() in favor of auth()->user()) via tlint.json configuration.
• Replace Manual Code Reviews: Shift repetitive convention checks (e.g., trailing commas, Blade spacing) from manual reviews to automated linting, freeing engineers for higher-value work.
• Onboard New Developers: Provide a self-service tool for new hires to auto-fix common issues (e.g., UseConfigOverEnv) via CLI commands (./vendor/bin/tlint fix), reducing ramp-up time.
• Deprecate Custom Scripts: Consolidate disparate linting tools (e.g., PHP_CodeSniffer, custom regex scripts) into a single, maintained package, reducing toolchain complexity.

When to Consider This Package

• Avoid if:

  • Your team doesn’t use Laravel (this is Laravel-specific).
  • You need deep static analysis (e.g., type safety, security vulnerabilities) → Use Psalm or PHPStan instead.
  • Your codebase is PHP 7.3/7.4 (dropped in v7.0.0) or Symfony <6 (limited support).
  • You require custom AST transformations → Consider PHP Parser directly or Rector.
  • Your team prefers strict PSR-12 compliance over Laravel conventions → Use PHP_CodeSniffer with SquizLabs/PHP_CodeSniffer rules.

• Consider if:

  • You want Laravel-specific linting (e.g., facades, Blade, migrations, request validation).
  • Your team struggles with inconsistent code style or technical debt in Laravel projects.
  • You need lightweight, fast linting (runs in milliseconds) without heavy IDE plugins.
  • You’re migrating to Laravel 8+ and want to enforce modern patterns (e.g., anonymous migrations, FQCN facades).
  • You want CLI-driven enforcement (e.g., tlint check, tlint fix) without complex setup.

How to Pitch It (Stakeholders)

For Executives/Stakeholders:

"tlint automates Laravel’s ‘unwritten rules’—like a spellcheck for PHP. It catches issues like hardcoded dd() calls, inconsistent facades, or messy Blade templates before they reach production, saving dev time and reducing bugs. For example, it can auto-fix 80% of new hire onboarding issues in minutes. Think of it as GitHub Copilot for code quality—but for Laravel’s conventions. With zero maintenance overhead (MIT-licensed, actively updated), it’s a no-brainer for teams scaling Laravel apps."

For Engineers:

*"tlint is a Swiss Army knife for Laravel codebases:

• Lint: Catch anti-patterns (e.g., Auth::user() instead of auth()->user()) with zero false positives.
• Fix: Auto-correct issues like trailing commas, Blade spacing, or FQCN facades via tlint fix.
• Customize: Extend rules via tlint.json (e.g., block route('home') in favor of named routes).
• CI Integration: Add a single command to block non-compliant PRs:

  composer require --dev tightenco/tlint
  ./vendor/bin/tlint check --preset=laravel
  

Best for: Teams tired of manual code reviews for Laravel-specific style guides. Try it on a PR—you’ll wonder how you lived without it."*