Config Laravel Package

Technical Evaluation

Architecture fit. fastd/config is a component of the FastD PHP framework (fastdlabs), not a general-purpose Laravel package. Laravel already ships a mature, framework-coupled configuration layer — Illuminate\Config\Repository, the config() helper, environment loading via Dotenv, and config:cache integrated into the bootstrap pipeline. Adopting fastd/config inside a Laravel application therefore means either (a) duplicating a solved problem, or (b) running two configuration containers side by side, which introduces split-brain risk where config('x') and $fastdConfig->get('x') diverge. The only architecturally coherent fits are narrow: a framework-agnostic shared library that cannot depend on illuminate/*, a FastD/Swoole-based service already in that ecosystem, or an isolated CLI/worker binary where a tiny readonly config loader is preferred over pulling in Laravel's container.

Integration feasibility. Composer installation is trivial (MIT license, standard PSR-4 autoloading). What is absent is everything around it: no Laravel service provider, no facade, no auto-discovery entry, no published config stub, no documented contract for how loaders are registered or how file paths are resolved. Any use in a Laravel context requires writing a provider plus an adapter from day one. That is a small but real amount of glue code that we would own indefinitely.

Technical risk. High, and concentrated almost entirely in the supply-chain and longevity dimensions rather than the code itself:

The codebase is probably small and readable, which is mitigating — a vendored fork is feasible — but "small enough to fork" is not the same as "cheap to own."

Key questions.

1. Does it implement any PSR contract (PSR-11 container, PSR-16 cache), or a bespoke get/set/has API?
2. What are the PHP version constraints, and do they clear our current and next LTS targets (PHP 8.2–8.4)?
3. Which loaders ship: PHP array files only, or also JSON/YAML/INI/ENV? What is the file-resolution and merge-precedence model?
4. Does it support dot-notation nested keys, and what does a missing key return — null, a default, or a thrown exception?
5. Does it interpolate environment variables, or is that expected to be pre-resolved by the caller?
6. Is there a compile/cache step, and is the cached artifact safe to ship per-deploy?
7. Is mutable state held in a singleton? Under Swoole/RoadRunner/Octane, does config survive or leak across requests?
8. What is the actual public API churn history across tags? Is the 2026-10-27 release an anomaly or the norm?

Integration Approach

Stack fit. Treat this as a library-internal dependency only. It is defensible inside a package we publish that must run on FastD, Laravel, and plain PHP without pulling in illuminate/support. It is not defensible as the configuration layer of a Laravel application, where config() is referenced by framework internals, third-party packages, and virtually every line of first-party code.

Migration path. Do not rip and replace. Sequence: (1) introduce a first-party ConfigInterface in our domain layer with the two or three methods we actually call; (2) implement LaravelConfigAdapter (delegating to Illuminate\Config\Repository) and, if justified, FastdConfigAdapter; (3) bind the interface in the container; (4) migrate call sites to the interface. This keeps fastd/config an implementation detail and lets us drop it by deleting one class. If the intent is to share config across a FastD service and a Laravel service, the interface boundary is what makes that tractable — not direct use of the package.

Compatibility. Three surfaces must be reconciled before any code is written: key naming (dot-notation vs. slash vs. nested arrays), precedence (file order → environment override → runtime override), and cache invalidation semantics versus php artisan config:cache. If both containers are active, define one as authoritative for each namespace and enforce it in review; undocumented dual sources of truth are the most common way this pattern fails six months later.

Sequencing. Timebox a one-day spike: install, load a representative config tree, exercise nested keys, missing keys, and an Octane-style long-running worker, and confirm the PHP constraint. Output is a go/no-go. If go, the adapter lands before any feature code touches it, and the package version is pinned exactly ("x.y.z", not ^x.y). If no-go — the expected outcome given 0 dependents and a single maintainer — the interface work still stands and we implement a ~40-line array loader in-house, which is cheaper to own than an unmaintained dependency.

Operational Impact

Maintenance. We inherit the full cost of an unmaintained transitive dependency: security patching, PHP-version compatibility (a new PHP minor can break an abandoned package's CI-less code), and Composer constraint conflicts as the rest of the tree moves forward. Budget either a quarterly "is it still installable?" check or a standing decision to vendor/fork it internally. Because it is MIT and small, forking is the pragmatic escape hatch — but a fork is a permanent line item, not a one-time task.

Support. There is no meaningful support channel: no dependents means no Stack Overflow corpus, no issue-tracker history from real users, and no third-party tutorials. Our team's institutional knowledge of this package will be exactly one or two engineers. Documentation quality is unknown and should be assessed in the spike by attempting to answer the key questions above from the repo alone — if that fails, that is the answer.

Scaling. Config loading is a cold-path, boot-time concern and will not be a throughput bottleneck at any scale we operate. The scaling risks are structural rather than volumetric: with config:cache, the artifact must be built per-deploy and per-environment, and any runtime mutation must be discarded. In long-running workers (Octane, Swoole, queue daemons), a mutable singleton config container is a cross-request state hazard — confirm readonly-after-boot semantics, or wrap it so mutation is impossible.

Failure modes. Ranked by likelihood × impact:

• Silent nulls — a missing key returns null and propagates as a wrong default rather than a startup error. Mitigate with schema validation at boot, not with more tests.
• Duplicate sources of truth — two containers, divergent values, environment-specific bugs that never reproduce locally.
• Cache staleness — config changed in the deploy artifact but not in the compiled cache; the classic "we deployed it but it's still using the old value."
• PHP file inclusion — if loaders include PHP config files, any path-traversal or write access to the config directory becomes RCE. Verify the loader's path handling and that config directories are not writable at runtime.
• Abandonment — the package stops installing on a future PHP minor and blocks an upgrade under time pressure.

Ramp-up. Negligible for engineers — a config container is a known shape and the API is small. The real ramp-up cost is organizational: nobody outside the adopting team will recognize this package, so every future engineer debugging config behavior starts from zero external references. That, combined with 3 stars and 0 dependents, means the package must justify itself against a ~40-line in-house alternative. On the evidence available, it does not — restrict adoption to the framework-agnostic shared-library case, gate it behind a first-party interface, and pin the version exactly.