Duskapiconf Laravel Package

Product Decisions This Supports

• End-to-end validation of config-gated behavior. Dusk drives a real browser against a real app server, so config() calls made inside a test never reach the process serving the request. This package closes that gap, letting a test flip server-side configuration and assert what the customer actually sees — the "config was changed" path, tested at the UI rather than mocked at the unit level.
• Build vs. buy (recommend: build). The capability is a small controller plus middleware — on the order of 50–150 lines. At 4 stars, 0 dependents, and a last release of August 2023, this should be treated as a reference implementation to read and reimplement internally, not a dependency to adopt.
• De-risks flag-driven roadmap work. If the roadmap includes feature flags, plan/tier gating, regional settings, third-party integration toggles (payment sandbox vs. live), maintenance mode, or rate-limit changes, this pattern makes each of those permutations testable in CI instead of by manual QA.
• Cheaper test matrix. Once the mutation mechanism exists, adding a new flag permutation to the automated suite is near-zero marginal cost, which changes the calculus on how many configurations you're willing to support.
• Not a product differentiator. No customer-visible surface, no revenue impact. It's a cycle-time and quality investment, so it should be justified on QA hours saved, not on capability.

When to Consider This Package

Consider the pattern if all of these hold:

• You already run Dusk with a real app server in CI (not just HTTP/feature tests).
• You have behavior that can only be verified in a browser and depends on server-side config.
• You have an isolated local/testing environment with no path to production.
• You're prepared to fork or reimplement — not composer require and forget.

Look elsewhere if:

• You're on Laravel Pennant. It offers first-class testing helpers (Pennant::activate) and is the idiomatic path for anything that is genuinely a feature flag. This package is not a substitute.
• Standard HTTP tests suffice. Pest/PHPUnit tests that rebind the container and call config() directly cover most "what if the config differed" questions without a browser at all.
• Your config is env-driven and cached. After config:cache, live mutation won't take effect without a restart; the whole premise breaks.
• You need maintained or vetted code. Zero dependents and a single maintainer mean no community security review and no compatibility guarantee — verify Laravel 10/11 support yourself before assuming it.

Non-negotiable if adopted in any form: the mutation endpoint is a privilege-escalation surface. Register routes only under app()->environment(['local', 'testing']), require authentication or a signed request, allowlist which keys may be mutated, and log every change.

How to Pitch It (Stakeholders)

Executives: A small open-source utility that lets our automated browser tests change application configuration on the fly, so flag-gated and integration-gated features can be verified end-to-end instead of by hand. It is not a strategic dependency — the same capability is roughly half a day of engineering — so the recommendation is to build it internally behind our environment guardrails rather than adopt an unmaintained, single-maintainer package. The value is cycle time: fewer manual QA passes per configuration permutation, and a cheaper path to supporting more of them.

Engineering: The problem it solves is real — Dusk hits a live server, so test-side config() mutations are invisible to the process under test. The package exposes a route that mutates server-side config from the test. That route is also the risk. If we build it: gate route registration on local/testing only, require a signed or authenticated request, allowlist mutable keys, log mutations, and never ship it in a production build artifact. Use Pennant for anything that's actually a flag; reserve this pattern for genuinely non-flag config (gateway stubs, limits, maintenance mode). Read the package's source as a spec — the abandoned-dependency risk outweighs the modest implementation savings.