- How do I install daftspunk/laravel-config-writer in a Laravel application?
- Install it with Composer using composer require daftspunk/laravel-config-writer. The package ships a service provider and facade that are auto-discovered in modern Laravel, and you may optionally publish its config file. After that, call the facade's write method with a dot-notation key and the value you want to persist.
- Which Laravel and PHP versions does laravel-config-writer support?
- The package's last release noted in the technical evaluation is 2023-08-10, so support for Laravel 11, Laravel 12, and PHP 8.3+ is unverified. Check the Composer constraints in the repository before installing, because they may block installation on newer frameworks. Run your own compatibility tests against your pinned Laravel and PHP versions.
- How do I update a config value at runtime with this package?
- Use the package's small public API, typically write($key, $value), with a dot-notation key such as app.name or branding.logo. The writer parses the corresponding config/*.php file, mutates the array value, and rewrites the file to disk. It is intended for setup wizards, admin settings screens, and provisioning scripts rather than request-path logic.
- Does laravel-config-writer preserve comments and formatting in config files?
- Comment and layout preservation is best-effort parsing, not AST-perfect rewriting. Unusual constructs such as env() calls, closures, concatenation, heredocs, computed values, and numeric keys can produce malformed PHP or silently drop expressions. Always test a round trip on your actual config files before relying on it.
- Does writing config files work when config:cache is enabled?
- No, not directly. Writes land on disk, but a booted Laravel application reads from the cached configuration, so changes remain invisible until you rebuild the cache with php artisan config:cache. Explicitly test the config:cache, write, config:cache cycle in staging and decide whether rebuilding the cache after every write is acceptable.
- Is laravel-config-writer safe for production or read-only container deployments?
- The package requires local, writable, on-disk config files, which makes it incompatible with read-only container images, ephemeral filesystems, immutable infrastructure, and env-var-driven 12-factor deployments. For stateless, horizontally scaled, or GitOps-driven setups, a database- or cache-backed settings store is the correct pattern. Use this package only behind an admin-only seam in a traditional monolith with a persistent writable volume.
- How does the package handle env() references, closures, and nested arrays?
- Handling is best-effort, so env() references, closures, concatenation, heredocs, computed values, and numeric or deeply nested arrays may be preserved, evaluated, or destroyed depending on the case. A corrupted config/app.php or config/database.php can cause a hard boot failure, not just a broken feature. Build a round-trip fidelity test suite that writes and re-reads every config file and asserts semantic equality.
- Can concurrent writes corrupt the config file or lose updates?
- Overlapping writes are a real risk: the evaluation warns of torn files or lost updates unless the package writes atomically and you serialize access yourself. Wrap writes in a lock, queue, or single-worker job so two admin requests cannot rewrite the same file at once. Also keep backups of boot-critical config files and validate the output before committing.
- Is laravel-config-writer maintained, and what are the alternatives?
- It is a narrow, single-maintainer package with a last release recorded as 2023-08-10, so bus factor is a concern and you should check the license and be prepared to vendor or fork it. Alternatives include database-backed settings models, cache-backed settings stores, and environment-variable configuration for 12-factor deployments. Adopt it behind a SettingsRepository interface so you can swap in a DatabaseSettings implementation later.
- How do I test config file writes and avoid code injection with this package?
- Write only admin-controlled, allow-listed, type-constrained values, because anything written becomes executable PHP evaluated at every boot and user-influenced paths are a code-injection vector. Test round-trip fidelity on every config file, the config:cache to write to config:cache cycle, and behavior under PHP 8.2/8.3 deprecation reporting. Pilot on a low-risk file such as config/branding.php in staging before touching boot-critical configuration.