Config Laravel Package

Product Decisions This Supports

• Build vs. buy for the config layer outside Laravel. The recurring question is whether every non-Laravel PHP service (Swoole/RoadRunner workers, CLI tools, internal microservices, queue consumers) should hand-roll config loading. This package is a candidate answer: a small, MIT-licensed configuration repository with file loaders, environment-specific overrides, dot-notation access, and a config set that can be resolved once and reused across long-lived workers.
• Standardizing a config contract across services. If we want one ConfigInterface shape across polyglot PHP services — instead of each team inventing get('db.host') semantics — evaluating this package forces the conversation about what the contract actually is (merge precedence, env var interpolation, caching, immutability).
• Roadmap sequencing for platform plumbing. This is a cheap spike, not a commitment. A one-to-two-day integration tells us whether a first-party config abstraction is worth a quarter of platform work, or whether teams are fine with per-service conventions.
• Use cases where it plausibly fits: 12-factor env-override configuration in containerized deploys; per-environment config sets merged at boot; compiled/cached config for high-throughput workers that must not re-parse files per request; and greenfield services that explicitly must not pull in illuminate/* or symfony/*.
• Dependency policy precedent. Adopting a 3-star, zero-dependent, single-maintainer component sets a precedent. The decision here isn't only "is this good code" — it's "what is our bar for third-party infrastructure dependencies," and that bar should be written down as a result.

When to Consider This Package

Adopt it when:

• You already run fastd/fastd or another Swoole-centric stack and want config semantics consistent with the rest of that ecosystem.
• You need a framework-agnostic config repository and the alternatives (Laravel's config component, full Symfony Config) are disproportionate to the service.
• You specifically want a cheap validation spike behind your own adapter, with a known exit cost.
• You can pin an exact version, vendor or fork the source, and accept that the maintainer is a single person.
• Diligence checks pass: PHP version support matches our runtime, PSR compliance where it matters (container, cache), tests present, and the release metadata is real — the listed last-release date is in the future, which needs verifying on Packagist/GitHub before anyone cites "actively maintained" in a decision doc.

Look elsewhere when:

• It's a Laravel app. illuminate/config is already installed, already cached via config:cache, and already understood by every engineer. There is no product reason to add a second config system.
• You need validation, schema, or typed config. Symfony's Config component with a tree builder, or hydrating into typed DTOs, is the mature answer.
• You need .env parsing. That's vlucas/phpdotenv; don't ask a config repository to do it.
• You need secrets management or hot reload. Config repositories read files; secrets belong in Vault/Secrets Manager, and reload-without-restart is a different problem.
• You need community support, security review, or a maintenance guarantee. Three stars, zero dependents, and one maintainer mean abandonment risk is the dominant risk, not code quality. For anything on the critical path of revenue, that is disqualifying on its own.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed, single-purpose configuration component from the FastD PHP framework family. The code risk is low — it's a narrow surface with a permissive license and a trivial exit path, because we would consume it behind our own interface. The portfolio risk is higher: three GitHub stars, zero known dependents, one maintainer. My recommendation is therefore pilot, don't standardize — use it to settle the config-abstraction question for our non-Laravel services, with a decision gate at the end of the spike. Cost of reversal is roughly one interface and a day of work. We should not put it on any revenue-critical path, and we should not adopt it in Laravel services at all, where the built-in config layer already does this job.

To engineering: Treat it as a config repository — loaders, environment override merge, dot-notation reads, and a resolved config set you can cache at worker boot. Integration is one to two days: wrap it in our own ConfigInterface, pin the version, add contract tests around merge precedence and env interpolation, and keep the adapter thin enough that swapping in illuminate/config or a hand-rolled loader is a single-file change. Two diligence items before we merge anything: confirm the published release tag actually exists (the recorded date looks wrong), and confirm PHP version support against our runtime matrix. If either fails, we build the 200-line loader ourselves — at this scale, that is a genuinely competitive option.