Core Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM must flag is a classification mismatch: marko/core is the kernel of the Marko PHP framework, not a Laravel package. It does not publish a service provider, facade, config stub, or any of the Laravel package-discovery conventions. There is no composer.json extra.laravel block, no Illuminate\Support\ServiceProvider subclass, and no documented integration bridge. Evaluating it as "a Laravel/PHP package" inflates its apparent fit; in reality it is a competing full-stack framework runtime. Architecture fit with an existing Laravel codebase is effectively zero without discarding Laravel's container, HTTP kernel, routing, and Eloquent — i.e., a rewrite, not an integration.

Integration feasibility. Composer-installable, MIT-licensed, and PSR-autoloadable, so the mechanical install is trivial. The problem is everything after composer require. Because the repo is a read-only split of the marko-php/marko monorepo, patches, issues, and release notes live elsewhere. That means: (a) version tags here may lag or desync from the canonical source, (b) any bug we hit requires a PR against a repo we don't control, and (c) there is no local fork-and-patch path that stays clean. Feasibility for a Laravel target: not feasible. Feasibility for a greenfield Marko app: technically feasible, organizationally risky.

Technical risk. The health signals are uniformly negative and should be read as a portfolio risk, not a maturity quirk:

Specific risks: no security advisory history means we cannot distinguish "no vulnerabilities" from "nobody is looking"; no LTS or semantic-versioning guarantee visible from this repo; no ecosystem of third-party Marko packages; and an unproven upgrade path. The countervailing signal is the opportunity score of 41.54 — middling, suggesting the underlying category (a lightweight, modern PHP framework core) has latent value even though this artifact has captured none of it. That is an argument to monitor, not to adopt.

Key questions to put to the maintainers before any further spend.

1. Is marko/core a mechanically generated split? What triggers a release here, and how is tag parity with the monorepo guaranteed?
2. Who is the named maintainer of record, and what is the bus factor? Is there a governance or sponsorship model?
3. Are there any known production deployments? Any reference users willing to talk?
4. What is the supported PHP version matrix, and is there a deprecation/LTS policy?
5. Does the framework assume its own DI container and HTTP kernel end-to-end, or are components individually consumable (i.e., can we cherry-pick a single concern into Laravel)?
6. What is the documented migration story off Marko if we need to exit?
7. Is there a security disclosure process (SECURITY.md, CVE feed, advisory database entry)?

Integration Approach

Stack fit. Poor for a Laravel shop, and this should be stated plainly in the decision record rather than softened. Marko targets the same layer of the stack Laravel occupies — application kernel, container, routing, request lifecycle. Two frameworks cannot own the bootstrap. The realistic fit options, in descending order of pragmatism:

1. Reference architecture only. Read the source for design patterns (container wiring, middleware pipeline, PSR-15 handling) and reimplement the ideas inside Laravel. Zero dependency risk, zero operational surface.
2. Isolated bounded service. If a specific Marko capability is genuinely superior, run it as a standalone PHP service behind HTTP, owned by a separate deploy unit. Does not touch the Laravel monolith.
3. Greenfield Marko application. Only defensible if the team has an explicit mandate to evaluate alternative frameworks and accepts single-vendor risk.
4. Direct integration into a Laravel app. Not viable. Reject.

Migration path. There is no incremental migration path, and this is the single most important finding. Laravel-to-Marko is not a strangle-and-replace operation; it is a ground-up rebuild of routing, auth, ORM access, queue workers, and the test harness. Any plan that describes this as a "migration" should be treated as a rewrite with a rewrite's cost profile — typically 3–6× the original estimate for a mid-size application.

Compatibility. Unknown and unverifiable from this repo alone. Before any pilot, pin an exact version, run composer why-not against the target PHP version, and diff the split repo's tags against the monorepo's. Assume no backward-compatibility guarantees until a maintainer states otherwise in writing. Composer's lockfile gives us reproducibility, not stability — a pinned broken version is still broken.

Sequencing. If leadership wants to proceed despite the risk read, the only defensible sequence is:

1. Two-week timeboxed spike, one senior engineer, non-production. Success criterion is a working vertical slice (routing + one endpoint + one persistence call + one test), not a "hello world."
2. Dependency and provenance audit — confirm split-repo sync, identify maintainer, check for a security policy.
3. Written exit-cost estimate — hours to remove Marko and restore the prior state. If we cannot estimate it, we cannot approve it.
4. Isolated pilot in a non-critical service with a hard rollback date.
5. Go/no-go gate reviewed by architecture and security. Default answer is no.

The spike is cheap; steps 4 and 5 are where the real budget lives. Do not let the spike's success imply approval for step 4.

Operational Impact

Maintenance. The maintenance burden inverts: with a healthy dependency, we consume upstream fixes; here, we would likely become the de facto maintainer of our own fork. Because the canonical work happens in a monorepo we don't control, every upstream change is a potential surprise, and every bug we file is a hope rather than a commitment. Budget for a named owner who tracks upstream activity — and be honest that this is a headcount cost, not a line item on a license.

Support. MIT license, community-only support, and a community that the star/dependent counts suggest is approximately empty. There is no vendor to escalate to, no SLA, no paid tier. Internal Slack-channel support means our own engineers become the escalation path. For a production system, that is an unacceptable single point of failure unless the system is genuinely low-stakes.

Scaling. Unproven at any scale. With zero dependents there is no public evidence of behavior under load, no published benchmarks, and no war stories about the failure modes that only appear past a few hundred requests per second. We would be the first to discover them, in production, on our own time.

Failure modes to plan for explicitly.

• Silent abandonment — upstream goes quiet; we discover it during a PHP minor-version upgrade. Mitigation: monitor commit cadence quarterly; treat six months of silence as a trigger.
• Split-repo desync — a fix lands in the monorepo but never reaches the package; we patch a phantom. Mitigation: verify tag parity before every upgrade.
• Breaking change with no semver discipline — a 0.x-style bump that isn't. Mitigation: pin exact versions, never use ^.
• Security gap — no advisory channel, so a CVE surfaces via a third party. Mitigation: add the repo to our dependency-scanning watchlist even if we don't adopt it.
• Key-person loss — the one engineer who understood Marko leaves. Mitigation: mandatory architecture documentation, which itself is unbudgeted cost.

Ramp-up. High and underestimated. This is a whole-framework mental model, not a library with a README — container semantics, lifecycle hooks, and conventions all have to be learned before productivity returns. Expect several weeks before a competent PHP engineer is net-positive, versus days for a typical Composer package. That ramp-up cost is incurred before we know whether the framework is viable, which is precisely the wrong ordering.

TPM recommendation. Do not adopt for any Laravel-adjacent workload. Classify as watch-list: revisit if the upstream monorepo demonstrates sustained commit cadence, gains named maintainers, publishes a security policy, and accumulates real dependents. The 41.54 opportunity score is a reason to keep it on the radar, not a reason to put it in a composer.json.