leafs/mvc-core
A core MVC layer for Leaf PHP applications, offering controllers, views, routing integration, and request/response plumbing to help organize code into a clean, structured architecture. Lightweight and extensible, it adds familiar MVC conventions to the Leaf micro-framework without unnecessary overhe...
Architecture fit. leafs/mvc-core is not a standalone framework — it is the shared substrate that leafs/mvc and leafs/api depend on. It supplies the opinionated "MVC glue" (routing/controller resolution, request–response lifecycle, and framework-level bootstrapping) on top of the lighter leafs/leaf micro-framework. For a TPM this reframes the question: you are almost never integrating mvc-core directly, you are choosing Leaf MVC or Leaf API as the framework and inheriting mvc-core transitively. Treating it as a directly consumable library is an architectural mismatch and a common early evaluation trap.
Integration feasibility. The mechanics are trivial — Composer install, PSR-4 autoloading, PHP 8.x — and will work on any standard LAMP/LEMP or containerized PHP-FPM target. The real feasibility constraint is the ecosystem: 4 GitHub stars and 0 dependents means the practical blast radius of adoption is you. There is no community corpus of Q&A, no third-party integrations, and no crowd-sourced battle-testing. Feasibility is therefore "technically green, ecosystem red" — a classic single-maintainer OSS bet on a low-traffic package.
Technical risk. Concentrated and non-obvious: (1) this package is core, so defects surface as framework-wide failures rather than isolated bugs, and it is the hardest layer to patch cleanly around in userland; (2) version coupling is tight — mvc-core majors are effectively coupled to leafs/mvc and leafs/api majors, and an unattended composer update can move all three at once; (3) the "last release 2026-10-22" signal is anomalous and must be reconciled before any planning — either it reflects a very recent push (healthy) or a date artefact in the metadata (a signal not to trust unverified package telemetry in the decision record); (4) bus-factor of one is the dominant risk, not code quality.
Key questions.
leafs/mvc or leafs/api (in which case mvc-core is transitive and should be version-pinned, not reasoned about directly), or are we pinning mvc-core to build a custom derivative on top of Leaf? The two answers produce very different ownership models.mvc-core + mvc/api + leafs/leaf) and who owns the upgrade cadence?mvc-core specifics rather than its public surface?Stack fit. Strong on a conventional PHP/SQL/Redis stack with Doctrine-less, lightweight-framework preferences; explicitly a poor fit if we are already standardised on Laravel or Symfony — Leaf occupies the same "opinionated application skeleton" slot and adopting it means running two framework idioms, two upgrade cadences, and two hiring profiles. Best-fit scenarios are greenfield small-to-mid services, internal tools, APIs, and prototypes where the "Leaf MVC structure without Laravel's weight" trade is genuinely valuable.
Migration path. Recommended sequencing: (1) adopt via leafs/mvc or leafs/api as a tracer — one bounded, low-blast-radius service — rather than importing mvc-core into an existing application; (2) pin the full dependency trio with exact-version constraints in composer.json and commit composer.lock as a governance artefact, not a build by-product; (3) verify composer audit and PHP version matrix locally and in CI before writing application code; (4) only after the tracer service has run a full release cycle, decide whether to standardise. Do not attempt to retrofit mvc-core into an existing Laravel codebase — the value proposition evaporates and the migration cost is a full rewrite for no functional gain.
Compatibility. Expect PHP 8.x with standard extensions; confirm against our base images and our lowest-supported PHP version rather than assuming. The critical compatibility axis is not PHP but the three-package version lockstep — mvc-core, mvc/api, and leafs/leaf. Establish a compatibility matrix in the repo and treat any independent bump of one leg as a breaking-change review.
Sequencing. Tracer service → hardening (pins, CI audit, PHP matrix) → one additional service if the tracer is clean → only then consider a written standard. Gate standardisation on evidence from at least two release cycles, not one, given the ecosystem's thinness. In parallel, run a cheap exit-cost spike: time how long it takes to fork mvc-core and apply a trivial patch. That number is the real determinant of whether this is a safe dependency.
Maintenance. This is where the package's profile (4 stars, 0 dependents, bus factor ~1) dominates the assessment. Plan for a contingent fork as a first-class operational scenario: mirror the repository internally, keep a patched fork ready, and document the fork-and-patch runbook before the first production deployment. Our maintenance obligation, not upstream's, is the number to budget.
Support. No vendor, no SLA, no commercial support tier, no community depth to fall back on. Internal support capability must be established deliberately — at minimum one engineer who can read and patch the core layer, plus the fork workflow above. Escalation to upstream is best-effort and must never appear in an incident runbook as a dependency.
Scaling. Adequately covered by horizontal PHP-FPM scaling and standard caching/queue patterns; mvc-core is a request-lifecycle layer and is not the scaling constraint. Realistically the ceiling is operational maturity, not architecture — smaller ecosystems tend to have thinner observability and profiling documentation, so budget for instrumenting it ourselves. Validate with a load test on the tracer service rather than relying on the framework's marketing claims.
Failure modes. Ranked, with mitigations: (a) upstream abandonment or slow CVE response — mitigate via fork readiness and composer audit in CI; (b) lockstep-version drift causing subtle framework-wide breakage — mitigate with exact pins and a compatibility matrix; (c) silent breaking change in a "core" patch release — mitigate by pinning and reviewing releases before pulling; (d) key-person loss on our side — mitigate by ensuring at least two engineers have touched the fork workflow; (e) lock-in to framework internals — mitigate by restricting customisation to documented extension points and avoiding monkey-patching.
Ramp-up. Low for anyone with PHP MVC experience — the mental model is conventional and onboarding is days, not weeks. Ramp-up is deliberately not spent learning the package but on the operational scaffolding around it: the fork workflow, the version-pinning discipline, and the compatibility matrix. The honest recommendation is to treat leafs/mvc-core as a viable prototype and internal-tool foundation, explicitly unsuited to a system of record or anything with a hard availability SLA, and to defer any standardisation decision until the tracer service has produced two clean release cycles of evidence and the release-date anomaly is verified.
How can I help you explore Laravel packages today?