Weave Code
Config Writer Laravel Package
larapack/config-writer
Larapack Config Writer lets Laravel apps persist configuration changes at runtime, updating, adding, or removing config keys in files. Useful for editable settings in admin panels without manual file edits.
Save changes to the configuration file in script.
Frequently asked questions about Config Writer
- What does larapack/config-writer actually do?
- It lets a Laravel application persist configuration changes back to disk at runtime, updating, adding, or removing keys inside the config/*.php files. This differs from Laravel's built-in config() helper, which only changes values in memory for the current request. The package is typically considered for editable settings screens where an admin changes options through a UI instead of editing files manually.
- Does larapack/config-writer support Laravel 10, 11, or PHP 8?
- No. The package targets the Laravel 5.x and PHP 5.x era, and its last release was on 2016-04-28 with no compatibility work since. Composer constraints will almost certainly fail to resolve against Laravel 8, 9, 10, or 11 and PHP 8.x. Even if you force resolution, Laravel 6 removed the array_get, array_set, and str_* global helpers that 2016-era packages commonly rely on, which causes hard runtime failures rather than deprecations.
- How do I install larapack/config-writer in a Laravel project?
- The normal path is a Composer require followed by registering the package service provider if auto-discovery does not apply. On a legacy Laravel 5.x app the constraints may resolve cleanly; on anything newer expect to vendor or fork the package and re-declare the illuminate/support constraints yourself. After installation, verify provider registration manually, since older packages predate Laravel's package auto-discovery conventions.
- Why do my config file changes have no effect after running config:cache?
- php artisan config:cache compiles all configuration into a single cached PHP file, so edits written to config/*.php are simply invisible to the framework. Opcache and the realpath cache can also serve stale values per node even after a file is rewritten. Persistence to disk does not guarantee the application reads the new value, so any design that mutates config files must also handle cache invalidation explicitly.
- Is larapack/config-writer safe to use in Docker or Kubernetes deployments?
- No, and the problem is structural rather than cosmetic. Containers and autoscaled pods typically have ephemeral or read-only filesystems, so a write lands on one instance's local disk and disappears on the next redeploy or rollout. Laravel's supported path for environment-specific configuration is environment variables, secret managers, and immutable images built at deploy time. Any requirement for runtime-tunable values is better served by a database or cache-backed settings store read into config at boot.
- Can concurrent writes corrupt the config file?
- There is no evidence of atomic writes using a temp file plus rename, and no locking in the package. Two simultaneous writes to the same config file can produce a truncated or partially written PHP file, which will break application boot. Because the config file is loaded very early in the framework lifecycle, this failure mode takes down the entire app rather than a single request.
- Is it a security risk to write Laravel config files at runtime?
- Config files frequently contain credentials, API keys, and encryption secrets, and writing to them places those values in a version-controlled, greppable, backup-scanned location. Depending on how the package serializes values, string interpolation into PHP files can also create code-injection paths, so the source must be reviewed rather than assumed safe. Either way, secrets end up in an unmanaged file outside your deploy history and rollback process.
- What is the best alternative to larapack/config-writer for an admin settings screen?
- Use a database-backed settings store such as spatie/laravel-settings, or a bespoke settings table hydrated into config inside a service provider. That approach gives you persistence, auditability, per-tenant scoping, and scale-out for free, and it works on immutable infrastructure. Only consider a file-level config package if the requirement is genuinely file-level and the package still passes a modern compatibility and security review.
- Is larapack/config-writer still maintained?
- No. It is archived and unmaintained, with its last release dated 2016-04-28 and no security patches, dependency refreshes, or compatibility work since. There is no maintainer and no CVE response path, so vulnerabilities would go unaddressed. Treat it as legacy code you would own entirely if you adopt it.
- How do I migrate an existing project away from larapack/config-writer?
- Start by inventorying every call site and identifying what actually depends on the persisted values. The strongest migration is to a settings table plus cache, hydrated into config in a service provider; a maintained config package is a second option only if the need is truly file-level. Forking and vendoring via a Composer path or VCS repository is the last resort, and a fork needs PHP 8 and Laravel version constraints, helper-removal fixes, atomic writes, input validation, and a test suite that never existed before.
Weaver
How can I help you explore Laravel packages today?