Laminas Development Mode Laravel Package

Product Decisions This Supports

• Build vs. buy (and the answer is usually "neither"): this is a commodity utility — a CLI wrapper that copies/removes a single config file (config/development.config.php from its .dist). The real decision is whether to spend engineering time reimplementing ~50 lines of file-toggling logic or adopt a maintained package. For a Laminas MVC shop, adoption is the cheaper path; for anyone else, a Composer script or Makefile target is cheaper still.
• Environment-strategy roadmap: forces an explicit decision about how config differs across environments. Choosing this package implicitly commits you to the Laminas convention of a committed development.config.php.dist plus a gitignored generated file — not to 12-factor env vars. That choice ripples into deployment, container images, and secret handling, so it belongs in an architecture decision record, not a sprint ticket.
• Developer-onboarding cost: development-mode enable|disable replaces "read the README, copy this file, don't commit it" tribal knowledge with a single documented command. Measurable as reduced setup friction for new hires and fewer "works on my machine" tickets.
• Incident prevention: the most common failure this addresses is a developer accidentally shipping local debug settings, or a deploy that inherits a leftover development.config.php. Safe toggling plus status reporting gives a verifiable pre-deploy check.
• CI/CD pipeline design: a scriptable, exit-code-bearing status command can gate builds and deployments. That is a small but real automation win versus a human remembering to delete a file.

When to Consider This Package

Adopt it when all of the following hold:

• You are on Laminas MVC (or a closely related Laminas skeleton) and already use the config/development.config.php.dist convention — the package is a thin convenience over a pattern you've already bought into.
• Your environment model is genuinely binary: development and production. There is no staging/QA/pre-prod matrix to model.
• You want zero runtime dependency — nothing is loaded in the request path; this is dev tooling only.
• Your team is small enough that a documented CLI beats an internal runbook.

Look elsewhere when:

• You are not on Laminas MVC. The package is framework-specific scaffolding; the same result is a two-line Composer script.
• You need more than two environments, per-service config, or runtime configurability — reach for vlucas/phpdotenv, container env vars, or a real config/secrets service.
• You are pursuing 12-factor / containerized deployment, where the whole notion of a committed dev-config file toggled on the filesystem is an anti-pattern; image parity across environments matters more than local convenience.
• You need feature flags, staged rollouts, or auditable config change history. This toggles a file; it does not give you a control plane, audit trail, or rollback.
• Supply-chain risk tolerance is low. At ~18 stars this is a low-signal dependency. Mitigating factor: its scope is so small that vendor-abandonment risk is easily absorbed by inlining the behavior — which is also the argument for not depending on it at all.

How to Pitch It (Stakeholders)

To executives: This is a zero-cost, BSD-licensed developer convenience, not a platform investment. It eliminates a recurring class of self-inflicted outages — local debug configuration leaking into production — by making the switch between dev and prod configuration a single auditable command instead of a manual file edit. Cost is effectively nil, runtime risk is nil (it's dev-only tooling, never loaded in production requests), and scope is deliberately narrow. The honest framing: it is a small quality-of-life win that only applies if we are already standardized on Laminas MVC. It should not appear on a roadmap as a line item, and it is not a reason to choose or stay on the framework.

To engineering: One command (enable / disable / status) replaces copy-the-dist-file-and-remember-not-to-commit. It's scriptable, so it drops into CI as a pre-deploy assertion; it adds no production dependency; and because the behavior is trivial, the lock-in is near zero — if the package stalls, we reimplement it in an afternoon. The tradeoff to accept consciously: it hardcodes a two-state dev/prod model and a filesystem-based config convention. If we're moving toward containerized deploys with environment variables, this package is a bridge, not a destination — adopt it to remove toil now, and expect to retire it when the config strategy changes.