Config Writer Laravel Package

Technical Evaluation

Package posture: Archived, unmaintained, last release 2016-04-28. This is the dominant fact of the evaluation. larapack/config-writer targets the Laravel 5.x era (PHP 5.x) and has received no compatibility work, security patches, or dependency refreshes since. The 39-star footprint and low opportunity score reflect that the ecosystem has moved on — not that the problem space disappeared.

Architecture fit: Poor for any modern Laravel deployment, and the misfit is structural rather than cosmetic.

• The package's only differentiation over config() is persistence to disk — it rewrites config/*.php at runtime. That directly contradicts the platform convention that config is deploy-time and immutable: env vars, secret managers, and container-fixed images are the supported path.
• The "correct" shape of this requirement — a settings screen, installer wizard, or runtime-tunable option — is almost always a database- or cache-backed settings store read into config at boot, not mutation of source files.
• Runtime file mutation is incompatible with immutable/ephemeral compute (containers, autoscaled pods, read-only root filesystems, blue-green rollouts). Writes land on one instance's local disk and vanish on redeploy.

Integration feasibility: Low without a fork.

• Composer constraints will likely not resolve against Laravel 8/9/10/11 or PHP 8.x. Expect to vendor/fork, re-declare illuminate/support constraints, and verify package auto-discovery or manual provider registration.
• Laravel 6 removed the array_get/array_set/str_* global helpers that 2016-era packages lean on; any such usage is a hard runtime failure, not a deprecation.
• Writing PHP config files means either var_export-style literal serialization (safe) or string interpolation (injection risk). This must be read in the source, not assumed.

Technical risk: High.

• Concurrency: no evidence of atomic write (temp file + rename) or locking. Two concurrent writes to the same config file can produce a truncated or corrupt PHP file that bricks application boot.
• Caching: php artisan config:cache makes file edits invisible, and opcache/realpath cache can serve stale config per node. Persistence ≠ effect.
• Security: config files frequently hold credentials and keys; writing them to disk places secrets in a version-controlled, greppable, backup-scanned location.
• Operational drift: settings become unmanaged state, outside deploy history and outside rollback.
• Abandonment: no CVE response path, no maintainer, no upgrade path to modern PHP.

Key questions for the requirement owner:

1. What is the actual user-facing need — an admin settings screen, an installer, or per-tenant tunables? Each has a better-supported alternative.
2. Does the target run on mutable VMs/bare metal, or on containers/ephemeral filesystems? If the latter, this package is disqualified outright.
3. Is the config directory writable in production today, and who approved that posture?
4. Is there existing usage of this package in the codebase, and what depends on it?
5. Are we prepared to fork, own, and maintain this code — and who is that owner?

Integration Approach

Stack fit: Only viable on a legacy Laravel 5.x monolith hosted on long-lived, writeable servers where the config directory is already mutable. On any Laravel 6+ or containerized stack, do not integrate — replace.

Migration path: Preference order, strongest first.

1. Replace with a settings table + cache. spatie/laravel-settings or a bespoke settings table hydrated into config in a service provider. Gets persistence, auditability, per-tenant scoping, and scale-out for free.
2. Replace with a maintained config package if the requirement is genuinely file-level and the package still passes a compatibility review.
3. Fork and vendor (composer path/VCS repository) only if the existing code cannot be touched at acceptable cost. Fork scope: PHP 8/Laravel version constraints, helper-removal fixes, atomic writes, input validation, and a test suite that did not previously exist.

Compatibility: Verify explicitly — supported PHP range, illuminate/* constraints, helper function usage, provider registration mechanism, and whether the write path survives config:cache. Assume nothing resolves; prove it in a throwaway branch.

Sequencing:

1. Inventory existing call sites and any persisted config files this package has already mutated (those are undocumented state, not source).
2. Diff those mutated files against version control to recover the true baseline config.
3. Introduce a thin internal SettingsService interface in front of the call sites — this is the swap seam and the only piece worth building regardless of which path is chosen.
4. Implement the interface against a DB-backed store; shadow-run it and compare outputs against the current behavior.
5. Cut over, remove the package, and add a regression test asserting config files are byte-identical to the repository baseline in CI. That test is the permanent guardrail against reintroduction.

Operational Impact

Maintenance: Upstream maintenance is zero and will stay zero. Any adoption converts into an internal ownership line item — fork upkeep, PHP upgrade churn, and security review on every framework bump. This cost is small in hours but permanent.

Support: No upstream escalation path, no issue tracker response, no security advisories. All incidents route to whoever owns the fork. Budget a named owner or do not adopt.

Scaling: Breaks on horizontal scale. Writes are node-local; N app servers means N divergent configs. Autoscaling, blue-green, and redeploy-based recovery all reset or split the state. Caching layers introduce per-node staleness on top of that. This is the sharpest operational constraint and alone justifies replacement in any multi-instance deployment.

Failure modes:

• Corrupted config file from a non-atomic or interrupted write — application fails to boot, and recovery requires filesystem access rather than a redeploy.
• Silent no-op from config:cache or opcache — the UI reports success; the application keeps serving the old value. Hard to detect, harder to explain.
• Lost writes on container restart or rollback — settings silently revert, and the rollback restores code while discarding the state users changed.
• Secrets on disk — credentials written into files that flow into backups, log scrapers, and repository history.
• Upgrade wall — a Laravel or PHP upgrade is blocked by the fork, converting a routine upgrade into a project.
• State/version drift — production config diverges from repository config, so no one can answer "what is actually configured" without shelling into a host.

Ramp-up: Low to learn the API (it is a small package), moderate to operate safely. An engineer can call it in an hour; understanding that the write may not take effect, may not survive a deploy, and may not be visible on other nodes takes a runbook and a design review. If a fork is required, add one to two engineer-weeks for compatibility work, tests, and the settings abstraction that should have existed in the first place.

Recommendation: Do not adopt for new work. Treat as technical debt where already present. Fund the SettingsService seam and a database-backed settings store instead, and add the CI check that keeps config files immutable. The package solves a real problem — runtime-settable configuration — with an approach the platform has since standardized away from; the correct decision is to adopt the requirement and reject the implementation.