Mvc Core Laravel Package

Product Decisions This Supports

• Framework selection (the real decision): leafs/mvc-core is not a library you choose — it is the shared substrate underneath Leaf MVC and Leaf API. The PM-level decision it informs is "Leaf vs. Laravel vs. Slim/Symfony" for a given service, not "should we install this package."
• Build vs. buy for small HTTP/API backends: Leaf's pitch is Laravel-style MVC ergonomics (routing, controllers, models, migrations) at a fraction of the dependency weight and boot cost. That makes it a credible candidate for internal tools, thin REST APIs, edge/CLI-adjacent services, and prototypes where full Laravel is overkill.
• Transitive-only dependency policy: Treat this as plumbing. If you adopt it, you adopt Leaf MVC or Leaf API and this comes along. Never import Leaf\Mvc\Core\* namespaces directly in application code — that couples your product to an unversioned internal seam and blocks a future framework swap.
• Roadmap risk input: 4 stars, 0 dependents, and a composite score of ~20 mean zero third-party ecosystem validation. The opportunity score (37) suggests modest headroom, but with no downstream consumers there is no evidence anyone has hardened it in production outside the maintainer's own frameworks. Any roadmap that assumes a growing Leaf ecosystem is speculative.
• Talent and onboarding planning: Choosing this stack narrows hiring to developers willing to learn a niche PHP framework. That is a hiring-pipeline cost, not a licensing cost — factor it into total cost of ownership comparisons against Laravel.
• Portfolio triage: For a PM with many services, the defensible use is a narrow, low-blast-radius service (internal admin API, webhook receiver, prototype) where rewrite cost is a sprint, not a quarter.

When to Consider This Package

Consider it only when all of the following hold:

• You are adopting Leaf MVC or Leaf API as the framework; this package is then an unavoidable, indirect dependency and should be pinned and vendored, not evaluated on its own merits.
• The service is small in scope and low in blast radius — an internal API, a prototype, a thin backend — where a full rewrite is cheap if the framework stalls.
• Your team is small and PHP-fluent, and one or two engineers can own the framework surface without an external support contract.
• You want Laravel-shaped conventions without Laravel's footprint — fast boot, minimal dependency tree, simple deployment.
• You are comfortable pinning exact versions and reading framework source when documentation runs out.

Look elsewhere when:

• You need the Laravel ecosystem by name — Sanctum/Passport, Horizon, Nova, Telescope, Cashier, first-party queue and broadcasting integrations, or a large package marketplace. Leaf has no comparable breadth.
• Long-term support, security SLAs, or vendor accountability matter. A single-maintainer project with 4 stars and 0 dependents is a key-person risk you cannot contract around.
• You have compliance, audit, or supply-chain review requirements. A near-zero-adoption package will not clear a dependency-risk gate, and a 2026-dated release on an otherwise dormant project warrants scrutiny of the actual commit history rather than release metadata.
• You need hiring liquidity — the PHP talent pool is trained on Laravel and Symfony; Leaf résumés are effectively nonexistent.
• The service is core revenue path with a multi-year horizon. Use Laravel or Symfony there and reserve Leaf for the periphery.

How to Pitch It (Stakeholders)

To executives: This is not a product decision, it is a dependency decision. The package itself is free and small; the cost is in ecosystem risk. Leaf offers a lighter-weight way to ship small PHP APIs than Laravel, which can mean faster cold starts and cheaper infrastructure on low-traffic services. The trade is that Leaf has a community measured in single-digit stars, one maintainer, and no downstream adopters — so we should use it only where a rewrite is a one-sprint contingency, and never on a revenue-critical path. Recommendation: pilot on one internal service, keep a documented exit path to Laravel, and revisit if the ecosystem does not grow.

To engineering: leafs/mvc-core is the shared core of Leaf MVC and Leaf API — routing, controllers, and model plumbing. It is a transitive dependency, not an API surface. Concretely: depend on leafs/mvc or leafs/api, pin exact versions in composer.json, commit the lockfile, and do not reference Mvc\Core namespaces from application code. Wrap anything you would not want to rewrite — auth, persistence, queue dispatch — behind our own interfaces so a framework swap is a mechanical change. Budget for reading source instead of docs, and assign one owner for upgrade testing. If we hit a wall on a first-party integration requirement, that is our trigger to stop and re-evaluate rather than patch around it.