Laravel Porto Laravel Package

Technical Evaluation

Architecture fit. The package is a scaffolding/architecture-enablement tool for the Porto pattern (container-based layered architecture: app/Containers/{Section}/{Container}/{UI, Actions, Tasks, Models, Data, Values}). It is not a runtime library so much as a convention + generator layer. That fits cleanly inside a Laravel monolith or modular monolith where you want domain-per-container ownership, but it deliberately diverges from stock Laravel layout (app/Models, app/Http/Controllers). Fit is good for greenfield or new bounded contexts; poor as a retrofit over an existing conventional Laravel app.

Integration feasibility. Technically low-risk to pilot: composer require --dev, publish config/stubs, run Artisan generators. Expect PSR-4 namespace additions (e.g., App\Containers\) and optional per-container service providers for routes/events. There is no meaningful production runtime surface, so the blast radius of trying it is small — this is the main reason it is worth a spike at all.

Technical risk. High from a supply-chain and longevity standpoint, low from a security standpoint:

• 1 star, 0 dependents, single-package release (last 2024-04-23) — effectively a bus factor of one, with a real abandonment probability.
• No community verification of Laravel/PHP version constraints; stub drift against Laravel 10/11/12 conventions is likely.
• Minimal test/CI signal visible; unverified vendor namespace.
• Not a runtime dependency, so vulnerability exposure is limited to dev tooling and generated code quality.
• Risk is concentrated in the pattern and stubs, not the dependency itself — which reframes the mitigation (vendor/fork rather than trust upstream).

Key questions to answer before adoption.

1. Does it generate only directory scaffolding, or does it also ship runtime abstractions (base Action/Task/Repository classes, registrars)?
2. What are the declared composer.json constraints for PHP and laravel/framework? Does it install on our current LTS?
3. Are stubs customizable/publishable, and do they encode the full Porto layering or a subset?
4. Does it enforce boundaries (architecture tests, Deptrac, PHPStan rules) or only create folders?
5. Is it a fork/derivative of Apiato, laravel-modules, or Mahmoud Zalt's Porto work? If so, which upstream should we track?
6. Who maintains it, and is there a stated support/versioning policy?

Integration Approach

Stack fit. Appropriate for PHP 8.x + Laravel 10/11 teams building a modular monolith, especially where multiple squads will own separate containers. Complements Inertia/Livewire/API-first builds; neutral to frontend choice. Conflicts to check: don't run it alongside laravel-modules or Apiato in the same tree — overlapping module/container conventions will confuse autoloading and route registration.

Migration path. Treat this as a dev-only tool and avoid a big-bang refactor:

1. Brownfield: introduce for new containers only; leave existing app/ structure untouched.
2. Validate with one real feature slice (one container, one Action, one Task, one Model, route + test) end-to-end.
3. If the pattern sticks, formalize path/namespace conventions in an ADR and encode them in architecture tests.
4. If upstream is unsuitable, vendor the stubs into the repo (or a private Composer package) and drop the external dependency — you keep the pattern without the maintenance liability.

Compatibility. Verify Composer constraints and run composer why-not against our Laravel version. Confirm namespace additions don't collide with existing PSR-4 roots, that generated service providers work under route:cache/config:cache, and that CI (Pint, PHPStan, Pest) passes on generated code. Check that generated classes are picked up by classmap authoritative autoloading.

Sequencing.

• Week 1: throwaway-branch spike, generate a reference container, measure developer feedback.
• Week 1–2: decide adopt / fork / vendor stubs / reject; document decision.
• Week 2–3: if adopted, codify stubs, add architecture tests, update onboarding docs.
• Ongoing: pin exact version, monitor upstream, keep an exit plan.

Operational Impact

Maintenance. With 1 star and 0 dependents, assume we are the maintainers. Pin the exact version, mirror the source internally, and budget a small recurring cost for stub updates on each Laravel major. The pattern's ongoing cost is larger than the package's: conventions must be policed or they decay.

Support. No upstream support channel, no issue-tracker SLA. Internal documentation and an owner (platform/architecture guild) are mandatory before rollout. Without that, the pattern becomes tribal knowledge.

Scaling. Organizationally, Porto scales well — container ownership maps to team ownership, and the package's scaffolding reduces boilerplate at container creation time. Technically, negligible runtime impact; watch classmap/autoload performance and route-provider proliferation as container count grows into the dozens.

Failure modes.

• Package abandoned or incompatible with a future Laravel major → generators silently break.
• Stubs drift from framework conventions → generated code fails static analysis.
• Container sprawl and cross-container coupling → the pattern degrades into folder theater.
• Namespace/autoload collisions with existing structure.
• Route/config caching issues if per-container providers aren't registered consistently.
• Team bypasses the pattern under deadline pressure, creating two coexisting architectures.

Ramp-up. The package is trivial to learn; the pattern is the ramp-up cost. Expect 1–2 weeks for a mid-level Laravel developer to be productive, plus a half-day workshop and a written convention guide. Budget architecture-review time for the first few containers; after that, generation + review is fast.

TPM recommendation. Do not take this as a production-critical dependency at 1 star / 0 dependents / score 0.105. Its value is as a reference implementation and stub source, not as a trusted vendor. Run a one-week spike, and if Porto fits the org, vendor or fork the stubs internally — that captures the productivity gain while removing the single-maintainer and version-drift risk. Evaluate Apiato or laravel-modules as better-supported alternatives if you need an actively maintained ecosystem.