Config Laravel Package

Technical Evaluation

Architecture fit. marko/config is the configuration loading/merging layer for the Marko PHP framework — not Laravel. That distinction drives the whole evaluation. If our stack is Laravel, we already have Illuminate\Config\Repository with dot-notation access, environment-aware loading, and caching; swapping in a framework-native loader from a competing micro-framework would be a net-negative integration with no upside. If we are evaluating Marko itself (or a Marko-based service), this package is a core, non-optional building block and fits cleanly by design. The functional domain — read config files, merge layers, resolve precedence — is well-understood, low-complexity, and rarely a source of architectural risk.

Integration feasibility. For a Marko target: high feasibility. composer require marko/config, point it at a config directory, and the framework resolves it. For a Laravel target: low feasibility without a custom adapter that maps Marko's merge semantics onto Laravel's repository — technically possible, almost certainly not worth the maintenance burden unless we are consolidating onto Marko. Note the repository is a read-only split: the real code, issue tracker, and PRs live in marko-php/marko. Treat this repo as a distribution artifact, not a project home.

Technical risk. Intrinsic risk is low (config loading is a solved problem). Ecosystem risk is moderate-to-high given the signal: 0 stars, 0 dependents, 0 listed score. Split-repo artifacts systematically under-report adoption — the monorepo is the real signal — so I would not read 0 stars as "abandoned," but I also cannot treat it as validated. Primary risks are (a) tight coupling to Marko core versioning, (b) single-maintainer/small-community bus factor, (c) unknown handling of secrets and env precedence.

Key questions.

• What Marko core version constraints apply, and does it depend on marko/framework or a discrete set of contracts?
• Which config formats are supported (PHP arrays, ENV, YAML/JSON)? Is there a documented merge precedence (file < env < runtime)?
• Is there config caching, and how are cache keys invalidated on deploy?
• How are secrets injected and kept out of merged output/logs?
• What is the PHP version floor and PSR-4/PSR-11 conformance?
• Who maintains it, and what is the release cadence in the monorepo?
• Is there a supported path to override the loader (needed for any adapter work)?

Integration Approach

Stack fit. Decision gate one: is the target stack Marko or Laravel? Marko → adopt natively, no adapter. Laravel → do not integrate; either consume Marko's config format conventions (arrays, env layering) manually, or reject. I would explicitly document "not a Laravel package" to prevent an engineer from pulling it in opportunistically.

Migration path. For Marko adoption: composer require marko/config (pinned to the monorepo-tagged version, not a floating split-repo ref), create the config directory, port existing settings into layered files, and validate precedence against the current environment. For teams coming from Laravel: a translation pass mapping config/*.php arrays and .env keys into Marko's structure — mechanical, but audit env-key renames since a silent miss produces null at runtime rather than an error.

Compatibility. Pin the Marko core version and this package together; treat them as a coordinated unit. Verify PHP floor against our runtime matrix. Because it is a read-only split, confirm the split tags track monorepo releases and that we are not installing a stale mirror.

Sequencing.

1. Spike (1–2 days): stand up a throwaway Marko app, load layered config, prove precedence and env overrides.
2. Risk review: confirm maintainer activity in the monorepo and license (MIT — clean).
3. Adapter decision: only if a Laravel/Marko hybrid is genuinely on the roadmap.
4. Pilot: one non-critical service; instrument config resolution at boot.
5. Rollout: standardize config layout and document precedence for the team.

Operational Impact

Maintenance. Low code churn expected for a config loader, but maintenance ownership is ambiguous: changes must go to the monorepo, and this repo carries no independent release process. Budget for "we may need to vendor or pin" if the monorepo stalls. MIT license removes legal friction.

Support. Community-only, small surface area. No vendor SLA. Escalation path is opening an issue in marko-php/marko — acceptable for internal tooling, questionable for customer-facing SLAs without a fork-and-patch contingency.

Scaling. Config merge cost is negligible at any realistic file count; it happens once at boot. The scaling concern is organizational, not computational: divergent config conventions across teams, and cache invalidation on deploy if config caching is used. Ensure config cache is rebuilt as part of the release pipeline, not lazily at runtime.

Failure modes.

• Precedence surprises — env values silently overriding or failing to override file values; mitigate with a boot-time assertion test.
• Missing keys returning null rather than throwing; add schema validation at startup.
• Secret leakage into merged config dumps or error pages; verify redaction.
• Stale config cache after deploy; tie cache-bust to release.
• Version skew between split-repo package and monorepo core; pin both.
• Abandonment — mitigation is the small code footprint; a fork is a realistic fallback.

Ramp-up. Minimal for PHP engineers; the concepts (layered config, env overrides) transfer directly from Laravel/Symfony. The real ramp-up cost is Marko framework familiarity, not this package. Estimate half a day for a competent PHP developer to be productive, one day to be confident in precedence semantics.

TPM verdict. Low-risk, narrow-scope component that is the right choice if and only if the target is Marko. The adoption signals are weak but structurally explainable by the read-only split; treat the monorepo as the source of truth and gate adoption on a one-day spike plus maintainer-activity check. Not a candidate for a Laravel stack.