Laravel Foundation Laravel Package

Technical Evaluation

Architecture fit. lucid-arch/laravel-foundation is the scaffolding layer for Lucid Architecture on Laravel — an opinionated, domain-oriented structure that organizes an application into Domains, Features, Operations (Jobs), and Services, with console generators to enforce that layout. Architecturally it is a poor fit for a greenfield Laravel build today not because the pattern is wrong — the service/action/repository decomposition is mainstream and defensible — but because this specific package is the deprecated distribution point. The maintainers explicitly redirect to lucidarch/lucid, and the repository is archived with a final release from September 2020. Any architecture decision here is really a decision about the successor project, not this one.

Integration feasibility. Effectively nil as a direct dependency. An archived package on a 2020 release cadence will carry Composer constraints against the Laravel 6/7/8 era and PHP 7.x; composer resolution against a current Laravel application will fail or force a downgrade of the framework itself. Even if a fork were coerced into resolving, the generators and base classes are coupled to internal Laravel APIs that have since moved (container bindings, console command signatures, service provider registration). The zero dependents and 16 stars are the decisive evidence: there is no installed base to inherit fixes from, no issue traffic to mine for known breakages, and no third party validating that the package still works against anything modern.

Technical risk. High and non-mitigable in place. Concretely: unpatched security advisories in the transitive dependency tree, permanent blockage of Laravel major-version upgrades, no upstream for bug fixes, and a bus-factor of zero. The only path that preserves the value is adopting the architecture as convention rather than as a dependency — folder structure, naming, and a thin in-house service layer — which removes the package from the risk surface entirely.

Key questions for the successor evaluation.

• Is lucidarch/lucid actively maintained, and what is its release cadence and last-commit date?
• Which Laravel and PHP versions does the successor officially support, and does it have a stated support window?
• What is the successor's test coverage and CI signal, and how many real dependents does it have?
• Which parts of the foundation package are conventions we can hand-roll versus framework code we genuinely need?
• If we adopt, what is the exit cost — how tightly would our domain code couple to Lucid base classes?
• Does the pattern's benefit (consistent structure across teams) justify a third-party architectural dependency at all?

Integration Approach

Stack fit. Treat this as a pattern evaluation, not a package evaluation. The relevant comparison is Lucid-style domain/operation decomposition versus plain Laravel service classes versus a modular monolith package (e.g., Laravel Modules) versus doing nothing. The 2020 package answers none of those questions; the successor may.

Migration path. Do not install lucid-arch/laravel-foundation in any environment, including a spike. Any existing usage should be treated as technical debt with a scheduled exit: extract the base classes and generators that are actually exercised, vendor them into the application namespace, and drop the Composer requirement. Vendoring is cheap here precisely because the package is small and the surface area in use is typically a handful of abstract classes and console commands.

Compatibility. Pin explicitly if anything is temporarily retained — PHP and Laravel constraints, plus a composer audit gate in CI. Because the package is archived, there will be no upstream compatibility releases, so every future Laravel upgrade becomes a manual fork-maintenance task.

Sequencing. Four steps, in order, each with a stop gate:

1. Discovery (1 week). Assess lucidarch/lucid on maintenance, supported versions, and test signal. If it fails the same tests, close the evaluation.
2. Convention spike (1–2 weeks). Stand up a throwaway Laravel app using only the Lucid folder conventions and hand-written base classes — no dependency. Measure developer comprehension and PR review friction.
3. Bounded pilot (one quarter). Apply to a single bounded context or a new service, with the convention documented in the repo rather than encoded in a package.
4. Standardize or abandon. Promote to a team-wide convention only if the pilot shows measurable review or onboarding benefit; the dependency decision stays separate and defaults to "no."

Operational Impact

Maintenance. The package is a maintenance liability with no upside: archived, deprecated, no releases since 2020, and no dependents generating patches. Adopting it transfers full ownership of a framework to the adopting team — a recurring cost against every Laravel upgrade, security cycle, and PHP version bump, for a package that provides what is ultimately a few hundred lines of scaffolding.

Support. There is no support channel. The redirect to lucidarch/lucid means issues filed against this repository are dead letters, and the successor's own community is small. An internal team would need a named owner for the vendored code and a documented escalation path that terminates in "we fix it ourselves."

Scaling. The architectural idea scales well organizationally — domain boundaries that map to team ownership, operations that map to queueable units of work, and a predictable place for every class. The package contributes nothing to runtime scaling and becomes proportionally more expensive as the number of applications or Laravel versions in the estate grows, since each one needs its own fork maintenance.

Failure modes. The realistic failure spectrum runs from blocked framework upgrades (certain, near-term) through CI composer audit failures and missed security patches (likely, ongoing) to undocumented behavioral drift as internal forks diverge across teams (certain if more than one team vendors it). The silent failure mode is the worst: because the code is old and quiet, teams may not notice it has become unmaintained until an upgrade is already committed to a roadmap.

Ramp-up. Low-to-moderate for engineers already fluent in Laravel — the concepts are conventional and the documentation, such as it is, lives with the successor project. The ramp-up cost that matters is not learning the pattern but learning our fork of it, which is undocumented by construction. Budget for a written internal convention guide regardless of which path is chosen; if that guide is written, the package becomes largely redundant, which is itself the strongest argument for skipping it.