- What does theofidry/laravel-yaml do?
- It is a Laravel service provider that adds YAML support to Laravel's configuration and translation loaders. It lets applications read config and lang files written in YAML while still allowing PHP arrays to be mixed in. The package is a legacy integration, not a native Laravel feature.
- Is theofidry/laravel-yaml still maintained?
- No. The last release was in 2016 and the repository is archived, so there is no upstream maintenance or security patching. Treat it as a source reference or a temporary fork candidate, not a trusted runtime dependency. Any use requires an internal owner for fixes and upgrades.
- Which Laravel and PHP versions does theofidry/laravel-yaml support?
- The package targets legacy Laravel and Illuminate versions from its 2016 release window; current Laravel and PHP versions are unlikely to satisfy its Composer constraints. There is no reliable modern support matrix, so you must run a compatibility spike against your exact Laravel and PHP versions. If it resolves only after changes, pin an exact commit or fork it.
- How do I install theofidry/laravel-yaml in a Laravel app?
- In a legacy app, require it with Composer and register the service provider in config/app.php if auto-discovery does not apply. Because the package predates modern Laravel, verify provider registration and avoid floating constraints. Pinning the exact version and testing a fork path is safer than assuming a normal install.
- Does it work with php artisan config:cache?
- Compatibility with php artisan config:cache is a key unknown and must be tested explicitly. YAML files and environment variables may not behave the same after config is cached, and the legacy loader may not participate correctly. Run a spike covering fresh config, cached config, changed YAML, and changed env values before relying on it.
- Which YAML parser does it use, and is it safe?
- The assessment flags the YAML parser version and unsafe object-tag handling as unknowns. You should not parse untrusted YAML, and any fork should disable object deserialization and pin a maintained parser. Review the parser dependency before allowing YAML from external sources.
- How does it handle environment variables and config merge precedence?
- The package's include behavior, merge order, environment-variable interpolation, and missing-file fallback are not clearly guaranteed by the archived project. Document these semantics from the source and test precedence between YAML, PHP config, and env overrides. Ambiguity here can cause production config drift.
- How should I test YAML config loading in Laravel?
- Add automated tests for fresh install, cached config, missing files, malformed YAML, environment overrides, and precedence between YAML and PHP files. Run those tests in CI against the exact pinned Laravel and PHP versions. Also test rollback to native PHP config in case the loader fails.
- What are alternatives to theofidry/laravel-yaml?
- Prefer native Laravel PHP config arrays for Laravel-only configuration. If YAML must be the cross-language source of truth, generate PHP config at build time or write a thin service provider around the maintained Symfony YAML component. A custom loader gives you control over caching, env handling, and security.
- Should I use theofidry/laravel-yaml in production?
- It is high risk for production: abandoned upstream, no security patches, low adoption, possible config-cache and env-resolution gaps, and a second configuration syntax for every developer and pipeline. Use it only in a frozen legacy application with a pinned fork, tests, documentation, and a rollback plan. Otherwise avoid it and migrate to native PHP config or build-time generated config.