Core Laravel Package

Getting Started

This is not a Laravel package. marko/core is the core of the Marko PHP framework — a standalone framework that predates or competes with Laravel's conventions rather than extending them. There is no service provider to register in config/app.php, no composer require that will "just work" inside an existing Laravel app, and no facade namespace that resolves against Laravel's container.

Minimal steps to actually get your hands on it:

1. Read the parent repo first. marko/core is a READ-ONLY subtree split of https://github.com/marko-php/marko. Issues, docs, examples, and PRs all live there. The core package alone has almost no runnable documentation.
2. Do not install into a Laravel project. Composer will pull it in, but it defines its own kernel, container, and service-provider contracts. You will end up with two competing bootstrapping models and PHP class conflicts on Container-style interfaces.
3. Start from the full framework skeleton (marko-php/marko), not the split core. The first real use case is scaffolding a Marko application and seeing how the core boots a kernel, registers providers, and resolves bindings — then comparing that mental model against Laravel's.

First practical use case: treat marko/core as a reference implementation of framework internals (container, provider lifecycle, kernel handling). The realistic day-to-day leverage for a Laravel developer is architectural study, not production dependency.

Implementation Patterns

Assume you are inside a Marko application, not Laravel. The core package supplies the framework's foundation — container, kernel, service-provider contract, and supporting utilities — and your application code consumes it indirectly through the skeleton.

Typical patterns you will encounter:

• Service providers as the integration seam. Just like Laravel, providers are where bindings and bootstrapping live. Register Marko providers on the kernel rather than relying on auto-discovery; there is no PackageManifest equivalent to lean on.
• Explicit kernel bootstrapping. You construct and boot the kernel yourself. There is no public/index.php magic from Laravel to hide the sequence — useful when you want to understand exactly when providers register() versus boot().
• Constructor/interface binding over facades. Framework cores in this style lean on the container resolving interfaces to implementations. Prefer constructor injection in application code; reserve facades (if the framework offers them) for edge cases.
• Version-locked pairing. Always pin marko/core to the same release as the parent marko/marko framework. The split package is generated at release time, so mismatching minor versions is the fastest route to "why does this method not exist."
• Cross-framework borrowing. If a pattern from marko/core (a leaner container, a simpler provider lifecycle) is genuinely better for a Laravel problem, port the idea into a Laravel service provider — do not try to bridge the two containers.

Gotchas and Tips

• READ-ONLY means exactly that. PRs opened against marko-php/marko-core will be closed. All fixes and feature requests belong in the monorepo. Budget time for a fork-and-split if you need a patched version.
• Zero stars, zero dependents, low score. This is a signal, not a formality. There is no community to lean on for the split package, and the surface area of "things someone else already fixed in core" is effectively empty. You are the first responder.
• No Laravel-style auto-discovery. Missing bindings will surface as container resolution errors at request time, not as install-time warnings. Enable whatever debug/dump mode the framework offers early.
• Provider ordering matters. Kernel boots providers in registration order; a boot() that assumes a binding from another provider will fail silently or late. Register foundational providers first.
• Don't debug through the split repo. Because it is generated, line numbers and file contents may not match the monorepo source. Cross-reference against marko-php/marko when tracing an error.
• Extension point to remember: the service-provider contract is the sanctioned place to inject behavior — subclass or implement it rather than monkey-patching kernel internals.
• Migration realism: if you already run Laravel, the cost of adopting Marko for a new service vastly outweighs the benefit at 0 dependents. Recommend it only for greenfield experiments where you control the full stack, and lock every version.