Roster Laravel Package

Technical Evaluation

Architecture fit: laravel/roster is a development-only Laravel package that detects dependencies, stacks, frontends, browser test frameworks, AI agents/editors, JS package managers, and codebase conventions from lockfiles, manifests, filesystem markers, and optional source scanning. It fits TPM-led inventory, onboarding, upgrade-readiness, and platform-consistency workflows rather than application runtime behavior. The Project facade, standalone ProjectManager, enum-based query API, and roster:scan JSON command make it easy to embed in CI jobs, internal dashboards, and scripts.

Integration feasibility: Low-friction adoption: composer require laravel/roster --dev, optional container usage, application cache-driver reuse, and a JSON-emitting Artisan command. Teams can pilot with php artisan roster:scan on a handful of repositories without changing deployment artifacts. The main integration work is not code-level; it is defining consumers of the output, validating detections against known project facts, and deciding whether results are advisory or gating.

Technical risk: Blast radius is low because the package is dev-only and MIT-licensed, but adoption risk is meaningful. With 167 stars, zero dependents, and a recent release cadence, it has limited external validation. Approach detection is explicitly best-effort pattern matching with confidence ratios, not an exact parser. JS transitive dependency classification differs by lockfile type, and multiple JS lockfiles are resolved by fixed precedence rather than erroring. Cached scans can persist in long-running processes until Project::fresh(). The package should be pinned and treated as an advisory signal until proven against representative repositories.

Key questions: What decisions will consume the scan output—onboarding checklists, upgrade planning, CI advisory checks, or enforcement? Which repositories are in scope, and do any use monorepos, nonstandard PSR-4 roots, or multiple JS lockfiles? Do we need approach detection at scale, or only package/stack detection? What is the acceptable false-positive/false-negative rate for gating? Who owns version upgrades and fallback if the package stalls? Which cache backend will CI and long-running workers use? Are source-scanning outputs permitted under internal code-handling policies?

Integration Approach

Stack fit: Strong fit for Laravel applications using Composer and an Artisan-capable environment. The package can scan the application base path or an explicit path, supports npm/pnpm/Yarn/Bun lockfile detection, and can scan PSR-4 roots plus app/ for conventions. It also works outside a Laravel container via ProjectManager, which helps internal tooling that scans many repositories. It is not a general-purpose SBOM or dependency-audit replacement.

Migration path: No runtime migration is required. Start by adding the package as a dev dependency in one or two representative repositories, run roster:scan, and compare the JSON against known stack facts. Then add it to the new-project template or platform baseline, followed by an advisory CI or scheduled inventory job. Only after detection quality and ownership are established should any team consider CI gating. Approach scanning should remain a separate opt-in step because it scans source files and is not persisted in cached scans.

Compatibility: Verify the package’s PHP and Laravel constraints against the oldest supported application in scope before broad rollout. Confirm cache-driver behavior in CI and Octane/queue environments; use Project::fresh() where stale memoization would mislead. Repositories with missing or corrupt lockfiles, multiple JS lockfiles, or unusual source layouts need explicit test coverage. JSON output should be treated as a versioned interface and validated after package upgrades.

Sequencing: 1) Run a proof of concept on 2–3 repositories with known stacks and dependency sets. 2) Validate package, stack, frontend, agent/editor, and JS package-manager outputs. 3) Pilot approach detection with --approaches on one codebase and review confidence thresholds. 4) Add the dev dependency to a project template or documented onboarding checklist. 5) Build an advisory scan job and aggregate JSON into an inventory view. 6) Revisit gating only after false-positive/false-negative tolerance and ownership are agreed.

Operational Impact

Maintenance: Low operational surface because the package is dev-only, but it still needs an owner. Pin the version, review changelog and releases on Laravel/PHP upgrades, and test JSON output stability. Zero dependents means the team cannot rely on broad community validation; maintain an exit plan, including forking under MIT if needed. Keep the package out of production images and deployment dependencies.

Support: Support burden should be modest if positioned as advisory. Provide a short runbook for failed scans, missing lockfiles, cache issues, and unexpected detections. TPMs should communicate that approach detection is confidence-based and may abstain or misclassify unusual files. Internal consumers should know which fields are authoritative versus best-effort.

Scaling: Per-repository scans are practical for CI and scheduled jobs, but source scanning for approaches is heavier and should be opt-in, cached externally, or run nightly rather than on every commit. For many repositories, aggregate JSON outside the Laravel app and avoid scanning all projects on every pipeline. Cache scan results where manifests and markers are unchanged, and avoid using long-running workers as the source of truth without Project::fresh().

Failure modes: Missing or malformed lockfiles, no configured cache driver, multiple JS lockfiles resolved by precedence, stale memoized results in Octane/queue workers, source-scan misses, and JSON schema changes after upgrades. Approach detection may be influenced by comments or string literals and may return no result when votes are split or below threshold. Fallbacks include direct scanning, Project::fresh(), disabling --approaches, manual validation against composer.lock/package.json, and pinning or forking the package.

Ramp-up: Ramp-up is low for Laravel developers: one command and a documented JSON consumer are enough for a pilot. A realistic TPM plan is a 1-day proof of concept, a 1–2 week pilot across a few repositories, and 2–4 weeks to add advisory CI/inventory reporting if ownership and validation criteria are clear. Training can focus on interpreting confidence ratios, cache behavior, and the difference between direct and transitive dependencies.