Tlint Laravel Package

Product Decisions This Supports

• Codifying a house style as executable policy. TLint encodes Laravel-specific conventions (fully qualified facades, no dd/dump/ray left in code, request validation in controllers, Blade spacing, anonymous migrations, route path conventions) as lint rules plus autofixers. That turns "we agreed on this in a PR comment" into a CI gate and a one-command remediation, which is a durable decision rather than a style-guide doc nobody reads.
• Buy vs. build for internal standards tooling. Building custom PHP_CodeSniffer sniffs or bespoke grep-based CI checks costs engineering weeks and then rots. TLint is MIT, Laravel-shaped, and covers the rule set most Laravel teams would otherwise hand-roll — a clear "buy/adopt" over "build."
• Where to invest in quality tooling relative to existing stack. TLint is not a replacement for Pint (formatting) or Larastan/PHPStan (type and static analysis). The decision it informs is additive: TLint occupies the "Laravel-idiom review" layer that neither of those covers. Sequencing it after Pint in CI keeps overlap low.
• Onboarding and ramp-up investment. Opinionated presets (Tighten, Laravel) let new hires and contractors inherit conventions passively instead of through review cycles — relevant when deciding how much onboarding documentation to write versus how much to enforce mechanically.
• Tech-debt remediation scoping. The formatter surface (v8.0.0 added ~14 autofixers) determines whether a "convention cleanup" epic is a one-sprint mechanical pass or a multi-sprint manual refactor. That materially changes roadmap sizing for legacy Laravel codebases.
• CI gating strictness. --only targeting, tlint.json config, and checkstyle output (v9.1.0) mean you can ship it in warn-only mode, ratchet it to blocking on changed files, or wire it into existing code-scanning dashboards. The decision is the enforcement posture, not the tool.
• Build-vs-integrate for editor and pipeline tooling. Checkstyle reporting means it plugs into existing CI report consumers rather than requiring a new dashboard — reduces the integration cost case.

When to Consider This Package

Consider adopting when:

• The codebase is Laravel and predominantly PHP, and the team already runs Pint and/or PHPStan — TLint fills the idiom gap rather than competing.
• You have recurring review comments about the same Laravel patterns (facade imports, env() in app code, request()->all(), stray dd()/ray() in commits). These are exactly its target rules.
• You want autofix, not just detection. The formatter set is the differentiator; a linter that only reports creates work, one that fixes creates throughput.
• You need CI-native output — the checkstyle reporter (v9.1.0) fits existing scanning pipelines.
• You're standardizing across multiple Laravel repos and want one shared tlint.json instead of per-repo bespoke checks.
• Maintenance risk tolerance is moderate: active releases through v9.7.0 with Symfony 8 and Laravel 13.x compatibility signals, PHP 8.3/8.4 in the test matrix, and a clear changelog.

Look elsewhere or deprioritize when:

• The stack isn't Laravel. Most rules are framework-idiom specific; value drops sharply for Symfony, vanilla PHP, or non-PHP services.
• You only need formatting. Pint/PHP-CS-Fixer alone is the lower-surface-area choice; adopting TLint without a formatting standard in place inverts the useful order.
• You need deep static analysis. TLint is AST-pattern matching, not type inference. Larastan/PHPStan is the correct tool for correctness risk; TLint handles consistency risk.
• You cannot tolerate rule churn. Two major versions (7.0.0, 9.0.0) removed or consolidated linters and formatters and dropped PHP 7.3/7.4 and the separate tformat.json config. Pin versions and budget for upgrade passes.
• Very large monorepos with tight CI budgets. Per-file AST parsing across thousands of files needs measurement before you make it a blocking gate; start on changed files.
• You need vendor-backed SLAs. This is a single-maintainer-community project under Tighten's stewardship, not a commercial product.

One data caveat for the decision record: the "dependents: 0" signal is misleading for a CLI tool — it isn't consumed as a library dependency, so Composer dependent counts understate real usage. Weight release cadence and changelog quality over that metric.

How to Pitch It (Stakeholders)

For executives (one paragraph): TLint is a free, MIT-licensed command-line tool from Tighten that checks and automatically fixes Laravel-specific code conventions. It's a low-cost, low-risk addition to our existing quality pipeline: no licensing spend, no vendor lock-in, reversible in an afternoon, and it is actively maintained with releases tracking current Laravel, Symfony, and PHP versions. The business value is reduced review friction and faster onboarding — conventions get enforced by tooling instead of consuming senior engineer time in code review, and legacy cleanup work becomes largely mechanical rather than manual.

For engineering leadership: This is an additive layer, not a replacement. It sits alongside Pint (formatting) and PHPStan/Larastan (correctness) and covers the Laravel-idiom rules neither addresses. Adopt in report-only mode first to measure violation volume and CI cost, then ratchet to blocking on changed files. Expect a modest one-time cleanup pass on legacy code using the autofixers, and pin the major version — the project has made breaking rule-set changes in 7.0 and 9.0.

For the engineering team: Install as a dev dependency, commit a tlint.json at repo root, run the Laravel or Tighten preset, and wire the checkstyle reporter into CI. Start with --only on the handful of rules that match our actual recurring review comments rather than enabling everything at once; expand once the baseline is clean. Treat it as a convention enforcer, not a correctness checker — it will not catch type errors or logic bugs, and we should not expect it to.