theofidry/laravel-yaml
Laravel YAML adds YAML configuration support to Laravel, letting you define app settings in readable .yaml files and load them through Laravel’s config system. It uses Symfony’s YAML parser for reliable parsing of YAML strings and files.
Architecture fit: Still weak for a modern Laravel application. The package remains a Laravel service provider for loading YAML configuration into Laravel’s config system, which only fits if YAML is already an authoritative config format across systems and the app is pinned to a compatible legacy stack. The v1.0.0-beta.2 release adds Laravel 5.1+ compatibility; that is a meaningful widening of the historical constraint, but Laravel 5.1 is itself long past end of life, so the change does not move the package into the range of currently supported Laravel versions. For Laravel-only configuration, native PHP config arrays remain more idiomatic, faster, and better supported by config caching and tooling. MIT licensing remains favorable and allows forking, but the package should still be treated as source reference rather than a trusted runtime dependency.
Integration feasibility: Low to moderate, marginally improved. The new release shows the project is not entirely frozen and that service-provider/constraint work has been done to reach Laravel 5.1+, which reduces the chance of an immediate Composer conflict on a legacy pinned app. However, the release is a beta, the compatibility claim covers a decade-old framework line, and it implies a PHP version band well below current runtimes. Integration with a current Laravel app would still require forking, adjusting illuminate/support constraints, validating service-provider registration/auto-discovery, and testing config-cache and environment-variable semantics. A short compatibility spike remains mandatory before any commitment.
Technical risk: High, essentially unchanged. Core risks persist: abandoned or near-abandoned upstream maintenance, no security patching, low adoption signals (no dependents or usage data supplied with this review), unknown YAML parser version, possible unsafe YAML object-tag handling, config-cache incompatibility, environment-variable resolution gaps, merge/precedence ambiguity, and lock-in to a non-standard configuration path. The new release adds its own risks: it is a beta with no stated stability guarantees, the compatibility claim is narrow and untested against modern Laravel/PHP, and the changelog gives no detail on how Laravel 5.1+ support was implemented or what regressed. The package still introduces a second configuration syntax that every Laravel developer and deployment pipeline must understand.
Key questions:
illuminate/support constraints?php artisan config:cache, and what happens when YAML files or env vars change after caching?Stack fit: Do not add this package directly to a greenfield or current Laravel application; v1.0.0-beta.2 does not change that. Consider it only for a frozen legacy Laravel app in the 5.1-era band with an exact compatible version, or as a reference implementation for a small custom loader. If YAML must remain the source of truth, prefer parsing YAML at build time and generating native Laravel PHP config, or write a thin service provider around a maintained YAML parser.
Migration path: Inventory all YAML files, environment substitutions, includes, and override rules. Re-run the compatibility spike on v1.0.0-beta.2 specifically, comparing against the previously evaluated release to identify behavioral differences. If the package works only after changes, fork it under an internal namespace, pin the exact commit or tag, and wrap it behind a small config-loader interface. Then either keep the wrapped fork temporarily or migrate YAML content into native PHP config or a generated config artifact. Treat the fork as an exit strategy, not a long-term platform.
Compatibility: Verify PHP version, Laravel/Illuminate constraints, Composer resolution, service-provider registration, config-cache behavior, YAML parser version, environment-variable handling, and test coverage. Treat the beta as unpinned behavior and pin the exact tag. Add CI coverage for fresh install, cached config, missing files, malformed YAML, and precedence rules. Avoid untrusted YAML and disable object deserialization.
Sequencing:
Maintenance: High if adopted as a dependency. A single beta release with a Laravel 5.1+ compatibility patch is not evidence of a maintained project; bug fixes, PHP/Laravel upgrades, and security reviews remain internal work. A named owner and fork maintenance budget are required. Without that, the package becomes configuration debt.
Support: Effectively none from upstream. Community support is minimal given low stars, absent dependent data, and beta status. The new release improves the optics slightly but provides no support commitment. Internal runbooks and tests must cover installation, config precedence, cache clearing, and rollback.
Scaling: Runtime YAML parsing is usually a boot-time cost, not a horizontal-scaling bottleneck, especially with config caching. Risk increases with large or numerous YAML files, repeated parsing, and cache invalidation complexity. Build-time generation scales more predictably and keeps production boot paths simple.
Failure modes: Malformed YAML, missing includes, unexpected merge precedence, env/cache mismatch, silent fallback to defaults, Composer conflicts after Laravel/PHP upgrades, and unsafe YAML parsing. Beta status adds upgrade risk: a later beta or 1.0 may change loading semantics without notice. Config-cache behavior remains especially important, since changes to YAML or environment variables may not take effect until caches are rebuilt.
Ramp-up: Low for Laravel developers to consume a YAML config file, but moderate to own and harden the package. Teams must learn YAML conventions, precedence rules, cache behavior, and fork maintenance. Documentation should be mandatory, and the release-specific delta for 5.1+ support should be captured in internal notes.
TPM recommendation: No-go as a direct runtime dependency for current or future Laravel work. The v1.0.0-beta.2 Laravel 5.1+ compatibility patch is a positive signal of activity but targets a framework line that is no longer supported and does not alter the core maintenance, security, and cache-consistency risks. Conditional go only for a legacy, pinned application where YAML is already authoritative, with a fork, tests, named ownership, beta version pinning, and a funded migration to native PHP config or build-time generation.
How can I help you explore Laravel packages today?