Product Decisions This Supports
- Framework evaluation: Informs whether to prototype or standardize on the Marko PHP framework, not whether to adopt a typical Laravel package.
- Build vs. buy/use: Helps decide between using Marko’s core framework and building an internal PHP framework layer; given zero stars/dependents, the “use” case requires strong strategic justification.
- Architecture spikes: Supports short-lived research spikes for greenfield PHP services, internal tools, or modular framework experiments where Marko’s core behavior is relevant.
- Vendor and dependency risk assessment: Flags the package as a read-only core split repository, meaning contribution, issue tracking, and roadmap visibility sit in the main
marko-php/marko repo.
- Roadmap gating: Suggests treating adoption as an exploration item until maintainer activity, documentation, release cadence, security posture, and ecosystem maturity are validated.
- Not a Laravel feature decision: This is not a standard Laravel package for adding capabilities to an existing Laravel app. It should not drive Laravel roadmap decisions unless the organization is explicitly evaluating Marko.
When to Consider This Package
Consider it only when:
- The team is deliberately evaluating the Marko framework or a Marko-based application, and needs its core package as part of that evaluation.
- You need a short, time-boxed proof of concept to compare Marko against Laravel/Symfony or an internal framework.
- Engineering has reviewed the main Marko repository, not just this read-only split, for release history, open issues, maintainer responsiveness, and security practices.
- The use case tolerates early-stage ecosystem risk and does not require commercial support, broad community answers, or a large package ecosystem.
- MIT licensing and the ability to inspect/fork the code align with your legal and dependency-governance requirements.
Look elsewhere when:
- You are building or maintaining a Laravel application and need a Laravel-native package.
- You require production-grade support, frequent releases, active maintenance, and a proven dependent base.
- The decision depends on community size, stars, dependents, tutorials, or third-party integrations as adoption signals.
- You need a stable framework choice for a long-lived product with low tolerance for vendor/ecosystem uncertainty.
- Your team is not prepared to track the main Marko repository and potentially contribute upstream rather than to this read-only repo.
How to Pitch It (Stakeholders)
Executive summary: marko/core is the read-only core of the Marko PHP framework, not a Laravel add-on. It is MIT-licensed and technically inspectable, but current public adoption signals are essentially absent: zero stars, zero dependents, and a low package score. Treat it as an evaluation-only framework dependency, not a production default. The right decision is to fund a small, time-boxed technical spike only if Marko is already on the architecture radar; otherwise, deprioritize it in favor of Laravel-native or more established PHP ecosystem options.
For engineering: Review the main Marko repository for maintenance cadence, test coverage, upgrade path, security process, and documentation. Confirm whether this split package is automatically published from the monorepo and how versioning maps to the framework. If we proceed, constrain adoption to a proof of concept with explicit exit criteria: maintainer responsiveness, compatibility with our PHP/runtime standards, and a clear contribution path upstream.
Recommendation: Do not position this as a strategic dependency or a Laravel package. Keep it in the “watch/evaluate” lane unless a concrete Marko-based use case emerges.