Lines Of Code Laravel Package

Product Decisions This Supports

• Roadmap sizing as a directional signal, not a schedule. A PHP-aware count (lines of code, comment lines, non-comment lines) gives a defensible "how large is this initiative relative to what we shipped last quarter" input. Use it alongside story points, dependency counts, and coverage — never as the sole basis for a delivery commitment.
• Build vs. buy vs. reuse. This is a commodity reuse decision, not a build decision. The library is small, single-purpose, BSD-3, and has no framework coupling. The real alternatives are cloc/tokei in CI, SonarQube, or PHPMetrics — not an in-house counter. It wins only when you need PHP-aware counts computed inside a PHP process you already own (an Artisan command, a scheduled report, a PR bot, a metrics dashboard).
• Codebase-health trend reporting. Per-module or per-directory growth over time ("app/Modules/Billing grew 40% while shipping three features") is the highest-value use case and the one least likely to be cheaply duplicated by SaaS you already pay for.
• Refactoring and capacity conversations. Trend lines on module size, paired with churn, support "should we invest in paying down this area" discussions with data instead of anecdote.
• Onboarding instrumentation. Flagging large, low-comment-density areas that are hard for new engineers to enter — a legitimate input to documentation and pairing investment.
• Soft CI guardrails only. "Flag PRs over N new non-comment lines for review" or "alert on >20% module growth sprint-over-sprint." Not a hard gate.
• Explicitly not supported: individual performance evaluation, productivity rankings, or velocity forecasting. LOC reflects language, style, and code generation, not value delivered. Any decision that ranks engineers by LOC is one this package makes worse.
• Metric integrity caveat. Releases 4.0.1 and 5.0.1 both fixed the same defect — multi-comment lines were double-counted, yielding negative non-comment LOC. Any dashboard built on this should be validated against a second source (e.g., cloc) before it influences a decision.

When to Consider This Package

Adopt when:

• You need LOC metrics inside a PHP/Laravel process you control — an artisan metrics:loc command, a nightly reporting job, a Slack digest, or a PR comment — and want PHP-aware parsing (tokenizer-based), so block comments, heredocs, and multi-line strings don't skew the numbers the way wc -l does.
• You want a clean, immutable LinesOfCode value object with linesOfCode, commentLinesOfCode, and nonCommentLinesOfCode accessors — trivial to serialize into storage and chart.
• A BSD-3, zero-telemetry, zero-vendor dependency is a procurement or compliance advantage over a SaaS code-quality platform.
• You are treating the output as a team-level trend signal, not a gate.
• Check first: it is a transitive dependency of phpunit/php-code-coverage, so it may already be in your composer.lock. Run composer why sebastian/lines-of-code before scoping — the marginal dependency risk may be nil.

Look elsewhere when:

• PHP version is the blocker. 5.x requires PHP 8.4+ (dropped 8.3); 4.x targets 8.3; 3.x targets 8.2. If your Laravel apps are on 8.2/8.3, you cannot take the current line without an upgrade or an isolated CI runner/container. This is the most likely reason to walk away.
• You need multi-language counts. This is PHP source only. Blade, JS/Vue/React, migrations, and config are invisible — which systematically under-reports full-stack team effort. For polyglot repos, tokei or cloc gives one number across the tree.
• You need a directory-level API. The counter reads one file at a time. Recursive traversal, .gitignore and vendor/ exclusions, and aggregation are your code, not the package's — budget for a small tested internal utility.
• You already have a metrics platform. If SonarQube, CodeClimate, or your coverage pipeline already produces LOC-adjacent data, adding this creates a second source of truth and a reconciliation argument you don't want in a steering meeting.
• You want complexity or risk, not size. Cyclomatic complexity, coupling, and churn are better defect predictors; PHPMetrics or PHPStan deliver more decision value per unit of integration effort.
• You need persistence, history, or dashboards. None included — results are immutable value objects you must serialize, store, and chart yourself.
• The codebase is small. Below roughly 10K LOC the signal-to-noise ratio and pipeline maintenance overhead aren't worth it.

How to Pitch It (Stakeholders)

Executives / engineering leadership

"This is a free, BSD-licensed PHP library that measures codebase size properly — separating real code from comments and blank lines, using PHP's own tokenizer rather than counting newlines. We'd use it in one narrow place: a lightweight internal report showing how each service grows quarter over quarter, so capacity and refactoring conversations are backed by data rather than anecdotes. It is not a vendor contract, it replaces nothing we pay for today, and it is roughly a one-day integration plus the directory-traversal utility we'd write ourselves. It carries zero runtime footprint in production. My recommendation is to treat it as optional infrastructure, not a roadmap item — and to explicitly commit that LOC is a trend indicator, never a measure of individual or team performance."

Engineering leadership

"The honest framing: this is a component of Sebastian Bergmann's PHPUnit ecosystem, and PHPUnit's coverage tooling already consumes it — so it is very likely already in our lock file. It's stable, tiny, and framework-agnostic: no service provider, no config, no production runtime cost. Two real caveats. First, the current major requires PHP 8.4+; if our apps are on 8.2/8.3 we either pin an older major or run it in a separate container. Second, the API is per-file, so we own the directory walk, the exclusion rules, and the aggregation — that's where the actual engineering cost sits. If all we want is a number in a dashboard, cloc in CI gets us there for near-zero effort. We should take this dependency only if we specifically need PHP-aware counts, computed in-process, from a value object we can persist."

Engineering teams

"Use this when you need PHP-accurate counts inside your own tooling — an artisan metrics:loc command, a nightly job, or a warning-level test that flags a module growing past a threshold. You get physical, comment, and non-comment LOC per file, parsed from tokens rather than newlines, so heredocs and block comments don't skew the numbers. Install with --dev. Two things to know before you touch it: the counter is single-file, so you write the recursive scan and the ignore logic; and pin the version to your PHP runtime rather than floating, because majors drop older PHP quickly. Please validate the first run against cloc — the project has a documented history of a multi-comment double-counting bug that produced negative non-comment LOC — and keep any CI check in warn-only mode for at least a quarter before anyone proposes making it blocking. Never surface the number per developer."