- How do I install laravel/roster in a Laravel project?
- Install it as a development dependency with composer require laravel/roster --dev. There is no service provider to register, no config file to publish, and no migrations to run. After that you can call the Project facade directly or run the roster:scan Artisan command.
- Which Laravel and PHP versions does laravel/roster support?
- Recent releases track the framework closely, with support for Laravel 10 through 13 and PHP 8.2 and above. PHP 8.1 support was dropped in v0.4.0, so check the PHP floor of the exact version you pin against the oldest application in your portfolio. Because releases are still pre-1.0, pin a tested minor and gate upgrades deliberately.
- How does Laravel Roster detect which packages a project uses?
- It reads your composer.lock, JavaScript lockfiles (npm, pnpm, Yarn v1 and Yarn v4 Berry), and configuration markers, and can optionally inspect source files for conventions. Detection is whitelist-driven off an internal Packages enum, which means internal, private, or newly released packages stay invisible until upstream adds them. Plan for a gap list and a pull request or vendor fork as a fallback.
- How do I check whether my Laravel app uses a specific package or version?
- Call Project::php()->uses('pestphp/pest') to test for a package, and usesVersion() when you need to assert a version floor. The same facade exposes packages(), production(), and dev() for the full inventory, plus stack and frontend checks such as Project::stacks()->uses(Stack::InertiaReact). The API surface is intentionally small, and results are cached after the first scan in a request.
- What happens if a project has no lockfile or a stale one?
- Roster is a static-file heuristic, so no lockfile means no roster result, and a stale lockfile produces a confidently wrong answer. The more dangerous case is the silent false negative: uses() returning false may mean the package simply was not detected rather than that it is absent. Treat undetected as unknown in your own reporting so downstream consumers cannot skip a migration step by mistake.
- What can Laravel Roster detect beyond Composer packages?
- It reports the application stack and frontend (for example Livewire, Inertia React, or Inertia Vue), browser test frameworks, configured AI agents and editors, and the JavaScript package manager indicated by the committed lockfile. It also flags conventions and approaches adopted by the codebase. All of this is read-only introspection of what the project contains, not a runtime component.
- Is it safe to ship laravel/roster to production?
- It is designed as a dev-only dependency: read-only, no runtime footprint, and effectively no conflict surface with production dependencies. Enforce composer install --no-dev in release builds so it never reaches production images. Keep it out of application boot paths and only invoke it from CI jobs or local tooling.
- How do I get JSON output or run Laravel Roster in CI?
- The package ships a roster:scan command, but the library API is deliberately small and does not give you a full report renderer or a stable output schema. Build a thin wrapper Artisan command that owns field naming and includes an explicit unknown or undetected state, then emit that as a JSON artifact. A scheduled CI job per repository writing to a central store is the usual fleet pattern.
- Can Laravel Roster detect private packages or path and VCS Composer repositories?
- Private and internal packages are generally invisible because detection keys off a fixed enum of known packages. Installed-version accuracy for path and VCS Composer repositories is also limited, so verify against composer.lock for anything you depend on in decisions. The practical mitigation is a maintained gap list plus an upstream pull request or a small vendor fork for your own detections.
- Is laravel/roster stable enough to adopt, or should I look at alternatives?
- It is pre-1.0 and has already shipped breaking changes on minor bumps, and adoption evidence is thin at around 166 stars with few listed dependents. Offsetting that is laravel/* ownership and a release cadence that tracks Laravel and PHP versions. Pin a tested minor, budget one to two days for a spike against real repositories, and compare results with composer show and composer outdated before rolling it out across a portfolio.