lucasp1337/laravel-loom
Laravel Loom is a small Laravel package that aims to make building and organizing application features simpler, with a lightweight API and sensible defaults. It is designed to slot into existing Laravel projects without heavy setup or boilerplate, giving developers a straightforward tool they can ad...
Architecture fit. Laravel Loom is a static-analysis and introspection package for Laravel applications: it scans the codebase via AST parsing, emits a versioned machine-readable schema of routes, controllers, models, events, dispatches, and (new in this release) model events, and exposes that surface to tooling — a loom:scan Artisan command, plus an optional MCP server for agent consumption and optional Laravel Boost guidelines/skill. Architecturally this is a development- and CI-time concern, not a request-path dependency, which is the right shape: it adds no runtime overhead to the application and fails without taking production down. The @internal tagging of optional-package classes plus the Livewire/MCP decoupling strengthens that boundary — the core scanner can be adopted without dragging in Livewire or the MCP server. Fit is strongest for teams that want a queryable map of their Laravel app for AI assistant grounding, impact analysis, or documentation generation; weaker for teams whose apps rely heavily on dynamic route registration or runtime service-container wiring, where any static scanner will have structural blind spots.
Integration feasibility. Installation is a standard Composer dev dependency plus config publish and a scan invocation — low integration cost, no schema migrations, no data store. The v0.4.0 changes that matter for feasibility: Laravel 11 is dropped outright, so the floor is now Laravel 12; Livewire and laravel/mcp are optional, so a plain install is lighter but MCP/Boost features are conditional on those being present; scan paths are now configurable with command options, which is the difference between "works on a single app" and "works on a monorepo or non-standard layout." Route discovery was extended to provider-loaded route files and group-attribute inheritance, which meaningfully widens real-world coverage. The main feasibility gap is documentation of the version matrix (PHP floor, Laravel 12/13 posture) — not derivable from these notes alone.
Technical risk. Three risks dominate. First, this is a 0.x package that shipped a framework-version drop in a minor bump; pre-1.0 semver permits it, but it means every upgrade is a review, not a routine bump. Second, the same release contains substantial internal refactors (AST facade, declarative dispatch rule table, ClassPrimitiveDiscovery, CollectingVisitor base, FQCN consolidation, route middleware fix). Refactors of scanner internals in the same cut as a schema freeze raise regression risk in output correctness specifically — and this class of tool fails silently with plausible-looking but incomplete data, which is worse than a crash. Third, the "schema 1.0 and MCP surface frozen" claim is a compatibility commitment made at 0.4.0 by a single-maintainer project; it is a good signal of intent but not yet an earned guarantee. Mitigating signals are real: PHPStan in CI, Pint drift enforcement, a benchmark baseline with model_events added, a SECURITY.md, and a published docs site.
Key questions.
loom:scan validate output against the schema before emitting, or can partial scans pass as complete?Stack fit. Assumes a Laravel 12 application on a supported PHP version, Composer-managed, with CI available. Adopt as require-dev only; keep it out of production images. It composes naturally with existing static-analysis tooling (Larastan/PHPStan) since the package itself is PHPStan-clean and enforces Pint — no culture clash in CI. Teams already using Laravel Boost or an MCP-based agent workflow get the most leverage; teams without that get a JSON artifact that is still useful for route/event inventories and impact analysis.
Migration path. From 0.3.x, treat this as a minor version with breaking edges: pin the exact version, regenerate the schema artifact, and diff the output against the previously committed one before accepting. Expect differences from the schema 1.0 freeze, the dispatch execution-mode field, new model_events in stats, and route-discovery changes (provider-loaded route files, inherited group attributes, corrected group middleware replacement) — these may add or correct entries rather than merely reformat. If the app is still on Laravel 11, the options are staying on 0.3.x with a documented pin/expiry, or sequencing the framework upgrade first; do not attempt both in one change. If any internal code was written against Livewire or MCP classes, stop — they are now optional and marked @internal.
Compatibility. Treat the emitted schema as the public API and the schema version field as the compatibility contract, not the package version. Pin package version in composer.json, commit generated artifacts, and gate CI on schema-version and shape assertions so an unexpected payload change fails the build rather than quietly reaching downstream consumers.
Sequencing. (1) Spike on a representative app or monorepo branch with configurable scan paths; measure scan time and inspect coverage gaps. (2) Pin, commit a baseline artifact, add CI validation. (3) Roll out the artifact to documentation or impact-analysis consumers. (4) Only then enable the MCP surface and Boost guidelines, with an explicit decision on auth and data egress. Keep Livewire support off unless Livewire is already in the stack.
Maintenance. Low steady-state cost: a dev dependency with no runtime footprint, no migrations, no infrastructure. The real cost is upgrade cadence — a single-maintainer 0.x project shipping breaking-adjacent changes in minor releases means scheduled review time each bump, not fire-and-forget. Budget a recurring upgrade slot or accept lagging a version behind.
Support and scaling. Support is community/single-maintainer; there is no vendor SLA. Scaling is along two axes: codebase size (scan wall-clock and memory on monorepos — the new configurable paths and benchmark baseline are the relevant levers) and consumer count (a frozen schema makes it safe to fan one artifact out to multiple tools). The docs site, Boost skill, and guidelines materially reduce onboarding cost, and SECURITY.md establishes a disclosure channel that previously did not exist.
Failure modes. (a) Silent incompleteness — scanner misses dynamic dispatches, closure routes, or provider-loaded routes and the artifact looks valid; partially mitigated this release but never eliminated, so add sanity thresholds (route/job/event counts) to CI. (b) Hard failure on unfamiliar syntax — now more robust around closures, dispatchIf/Unless, and Event facade aliases, but new syntax will keep arriving. (c) Regression from the internal refactors — caught only by artifact diffs, not by unit tests alone. (d) Version skew between the frozen schema and downstream consumers. (e) Laravel upgrade lockout if the package lags a new framework major.
Ramp-up. A Laravel-fluent engineer can run a first scan in under an hour; the learning curve is in interpreting the schema (what a dispatch site is, how execution mode is attributed, what is inferred vs. declared) rather than in operating the tool. The published docs site, Boost guidelines, and skill shorten that meaningfully. Plan for one engineer to own the artifact contract and the CI gate — that ownership, not the install, is what keeps this from decaying into an unmaintained generated file.
How can I help you explore Laravel packages today?