Laralint Laravel Package

Getting Started

Install as a dev dependency:

composer require glhd/laralint --dev

Run the linter directly:

vendor/bin/laralint

Start with a single directory or file to see the kinds of issues it flags before running it across the whole codebase:

vendor/bin/laralint app/Http/Controllers

Look first at the generated/published config (if you need to customise rules). Publish it with:

php artisan vendor:publish --tag=laralint-config

The first practical use case is auditing an existing Laravel project for common anti-patterns (e.g. env() calls outside config, missing declare(strict_types=1), incorrect facade usage) and then wiring the command into CI so new violations don’t creep in.

Implementation Patterns

• CI gate: Add vendor/bin/laralint --no-progress to your GitHub Actions / GitLab CI pipeline. Fail the build on violations so the ruleset becomes enforceable.
• Changed-files mode: In pull requests, run only against changed files to keep feedback fast. Combine with git diff --name-only or a CI helper.
• Baseline existing issues: If adopting on a legacy codebase, generate a baseline file (check the package docs for --baseline) so existing violations are ignored and only new ones fail the build.
• Pre-commit hook: Use Husky, CaptainHook, or a simple Git hook to run vendor/bin/laralint on staged files before commit.
• Custom rules: Extend the linter by writing custom fixers/rules and registering them in the published config. This is useful for enforcing project-specific conventions (e.g. naming, directory structure).
• IDE integration: Configure PHPStorm’s “External Tools” to run the linter on the current file, or use the command output in your terminal workflow.

Gotchas and Tips

• Laravel version support: 0.2.0 adds Laravel 13 support. If you’re still on an older Laravel version, pin to ^0.1 until you upgrade. The package generally follows Laravel’s major releases, so keep it in sync with your framework version.
• Opinionated defaults: Laralint ships with a preset ruleset. Review the published config before enabling everything globally—some rules may be too strict for your team’s style.
• Config quirks: The config file may use a rules array where true enables a rule and false disables it. Double-check the exact key names; typos are silently ignored in some linter implementations.
• Debugging: Run with -v (or --debug where available) to see which rules are being applied and why a file is flagged. If a rule seems missing, confirm it’s enabled and that the file path matches the rule’s scope.
• Extension points: Custom fixers typically need to implement the package’s fixer interface and be registered in the config. Keep custom rules in a dedicated namespace (e.g. App\Support\Laralint) and cover them with tests.
• Performance: On large codebases, the full run can be slow. Use path filters (app/, src/) and exclude vendor/generated directories in the config.