Yaml Laravel Package

Technical Evaluation

Architecture fit. pragmarx/yaml is a thin Laravel service provider that swaps Laravel's native PHP config loader for a Symfony Yaml-backed one, letting config/*.yaml files be read through the standard config() helper. It sits directly on the application bootstrap path — the same path php artisan config:cache and every config() call depend on. That is a high-blast-radius integration point for a package with 114 stars, zero dependents, and a May 2020 release. The conceptual fit is narrow: YAML config is attractive only if config is authored or consumed outside PHP (GitOps pipelines, shared service config, non-PHP tooling), otherwise it substitutes a zero-dependency native mechanism for a third-party one with no functional gain.

Integration feasibility. Mechanically simple — Composer install, provider auto-discovery, publish config. But feasibility collapses at the edges: (1) Laravel's bootstrap internals (LoadConfiguration, provider ordering, config repository hydration) have shifted across L8–L12, and a 2020-era provider is unlikely to be validated against current versions; (2) YAML is static, so Laravel's env() interpolation — the backbone of 12-factor config — has no obvious equivalent, creating a secret-injection gap; (3) interaction with config:cache is unverified and is a hard blocker if broken. A one-day spike against the target Laravel/PHP version answers most of this.

Technical risk. High, concentrated in maintenance and boot-path fragility. Unmaintained for five years, no dependents to surface breakage, no CVE-monitoring footprint. YAML parsing adds failure modes PHP includes don't have (indentation, anchors, type coercion — yes becoming true, unquoted version strings), and Symfony Yaml's object-instantiation behavior requires explicit safe flags. A parse error is a boot-time outage, not a degraded feature.

Key questions. Does it support the target Laravel and PHP versions? Does config:cache work, and is YAML re-parsed per request without it? How are environment-specific secrets injected? Can YAML and PHP config coexist, or is it all-or-nothing? What are the symfony/yaml and illuminate/support constraints, and do they conflict with the rest of the lockfile? Is there a maintained fork?

Integration Approach

Stack fit. Poor as a wholesale config-format replacement; plausible only as a narrow, opt-in loader for one non-critical config domain (feature flags, tenant settings, pipeline-authored policy). Treat the package as a reference implementation, not a dependency of record.

Migration path. Do not convert config/*.php. Instead: author the narrow domain in YAML, validate it in CI, and compile it to a cached PHP config file at build/deploy time using a small in-house loader (~50 lines around Symfony\Component\Yaml\Yaml::parse with safe flags and an env-substitution pass). This captures YAML's authoring benefits while keeping Laravel's native, zero-dependency, config:cache-compatible runtime path. If runtime YAML is a hard requirement, fork the package under an internal namespace so upgrades are yours to control.

Compatibility. Pin and test the exact matrix: PHP 8.1–8.3, target Laravel major, symfony/yaml major. Confirm behavior under config:cache, config:clear, Octane (worker-boot persistence), and read-only filesystems. Verify no conflict with packages that read config() during provider registration.

Sequencing. (1) Half-day spike: install in a throwaway branch, boot, run config:cache, dump resolved values. (2) Security review of Yaml flags and secret handling. (3) If viable, isolate to one domain behind an internal ConfigSource interface. (4) Ship behind a feature flag with a PHP fallback path. (5) Decide on fork-vs-compile-to-PHP before any second domain adopts it.

Operational Impact

Maintenance. You inherit it. Five years stale, MIT-licensed, fork-friendly, but no upstream velocity and no dependents creating upgrade pressure. Budget ongoing internal ownership — compatibility patching on every Laravel/PHP upgrade — or avoid the runtime dependency entirely via the compile-to-PHP approach.

Support. No vendor. Community issue tracker likely dormant. Escalation is internal engineering, which is fine for a small loader and expensive for a bootstrap-critical one.

Scaling. Parse cost is per-boot, not per-request, if caching works; if it doesn't, every request re-parses YAML — a measurable regression at scale and a silent one. Confirm under Octane, where config is loaded once per worker and staleness becomes a deployment concern.

Failure modes. Malformed YAML ⇒ application cannot boot (hard outage, no graceful degradation). Missing env interpolation ⇒ secrets committed to the repo or bespoke templating. Silent type coercion ⇒ subtle config drift. Composer resolving a new symfony/yaml major ⇒ behavior change with no code diff. Laravel upgrade breaking provider bootstrapping ⇒ upgrade blocked across the whole app.

Ramp-up. YAML syntax is trivial; the package's loader semantics and Laravel's bootstrap internals are not. Debugging a boot failure here requires understanding both, and documentation is thin. Expect tribal knowledge to accumulate around one or two engineers — a bus-factor cost disproportionate to the benefit.

Recommendation. Score of 2.2 is defensible: the package solves a real but rarely compelling problem, and its maintenance signal disqualifies it from the bootstrap-critical path. Adopt YAML as an authoring format compiled to native PHP at build time; do not adopt this package as a runtime dependency.