Dev Pack Laravel Package

Product Decisions This Supports

Dev toolchain standardization — not product feature work. irstea/dev-pack is a Composer meta-package: a require-dev block that pins a coherent set of dev tools (PHPUnit, PHPStan/Larastan, PHP_CodeSniffer, PHP-CS-Fixer, Rector, PHPMD, possibly Pest or Psalm) so every repository runs the same versions. The decisions it informs are internal hygiene questions: "Should we adopt this new static analysis tool?" is answered by whether it lands in the shared pack; "Why do two teams get different CI results?" is answered by version skew the pack exists to eliminate.

Onboarding friction and environment parity. A one-line composer require --dev irstea/dev-pack replaces a multi-step setup and collapses hours of "works on my machine" debugging into a repeatable baseline. This supports decisions about how much setup friction is tolerable for new engineers and whether tool drift is quietly causing CI/desktop mismatches.

Build vs. buy — narrowly scoped. Inside the originating organization this is a clear "buy the pattern" answer: don't hand-assemble dev tooling per team. It offers no signal for external build-vs-buy decisions — the package is private, unscored (0), has zero dependents, and lives on gitlab.irstea.fr.

A template for the meta-package pattern. The most transferable product insight is structural: pin a toolchain in one place, propagate upgrades org-wide with a single version bump. Teams outside the org should copy the pattern into their own template repo, not take a dependency on this package.

What it does not support: roadmap prioritization, pricing, market positioning, or any customer-facing decision. Treat it as internal infrastructure hygiene, not a product asset. It contains no runtime code, no Laravel service provider in production, and no database footprint.

When to Consider This Package

Consider it if:

• You are inside IRSTEA / INRAE (or a closely affiliated group) with network access and GitLab credentials for gitlab.irstea.fr.
• You run a portfolio of Laravel/PHP services and want a single shared quality gate — identical tool majors, rule sets, and CI behavior across repos.
• You want a canonical, low-friction answer to onboarding: one require-dev line, one credentials file, done.
• You value centralized upgrade cadence — bump the pack, propagate tool updates across the estate on the next composer update.
• You want a reference implementation of toolchain consolidation to replicate in your own template repository.

Look elsewhere if:

• You need the actual tooling — depend on PHPUnit, PHPStan, PHP-CS-Fixer, etc. directly. This package only aggregates; it contains no code of its own.
• You are outside the organization, or you require community support, public docs, or a stated release cadence. Zero stars, zero dependents, score 0, and a French-only description mean no external validation exists.
• Your apps must legitimately diverge from the bundled tool majors (e.g., one service needs PHPUnit 10 while the pack pins ^9). A meta-package's whole value is uniformity; if you need divergence, you lose the benefit while inheriting the constraint.
• You run a polyglot or legacy PHP estate where a single internal QA toolchain doesn't fit the domain.
• An internal owner and update cadence do not exist. An unmaintained meta-package ages badly — tools release majors faster than internal repos are visited, and you'll be six to twelve months stale by default.

Pre-adoption checklist (before committing):

1. Read vendor/irstea/dev-pack/composer.json — it is the documentation; the diff between versions is the release note.
2. Confirm the pack is tagged/released (semver), not dev-main-only.
3. Check PHP and Laravel constraint overlap against your oldest supported runtime and CI matrix.
4. Inspect for scripts, plugins, or config blocks; verify allow-plugins behavior.
5. Confirm whether a private Packagist/Satis exists, or direct VCS access is the intended path (the latter is slower and more brittle).
6. Pin to a tag or explicit commit SHA — never dev-main, which silently changes your quality gate on every composer update.
7. Establish a named owner, a quarterly bump reminder, and a documented local-fork path before you need it.

Migration sequencing: inventory current require-dev across repos → resolve the pack in a sandbox composer.lock → pilot on one low-risk repo → diff the lock file deliberately → run the full quality gate plus composer install --no-dev → codify in the shared CI template → roll out to the fleet. Attempting fleet-wide adoption first is the classic mistake; the blast radius is every consumer at once.

Failure modes to design against: credential expiry breaking every build simultaneously (use a long-lived read-only deploy token as a CI secret; alert on auth failures as a distinct class); ref deletion or force-push against a mutable ref; the pack bumping its own PHP floor and breaking older runtimes; constraint deadlock blocking a security patch elsewhere; post-install-cmd or plugin surprises; accidental require instead of require-dev leaking dev tools into production artifacts.

How to Pitch It (Stakeholders)

To executives: This is an internal convenience wrapper, not a product or platform investment. Strategic upside and risk are both near zero, and it offers no external leverage or competitive signal. Fund it only as a small developer-experience line item — one owner, a quarterly tool-version bump, and credentials in CI — and explicitly do not count it toward innovation or platform goals. If the owning team can't name an owner and a refresh cadence, the right call is to copy the pattern into a template repo rather than take the dependency.

To engineering leadership: The value is the pattern, not the artifact. A single pinned meta-package replaces N require-dev lines, standardizes static analysis, code style, and testing across every repo, and turns a toolchain upgrade into a one-line version bump. It reduces version skew, onboarding friction, and "works on my machine" failures. The trade-offs are also real: consuming the pack means accepting the maintainer's tool majors, rule sets, and update cadence as a governance decision; there is no external community to fall back on; and pinning to dev-main would silently change your quality gate on every composer update. Adopt only after inspecting the pack's composer.json, pinning to a commit SHA, wiring it into the shared CI template, and documenting a local-fork exit path. Keep a production composer install --no-dev check in the pipeline to confirm dev tooling never leaks into the runtime artifact.

To engineering teams: Setup is roughly an hour of developer-facing work — configure the GitLab token, composer require --dev, remove now-redundant individual dev dependencies. The real project is governance: distribute credentials to laptops and CI runners, decide the pinning policy, document the fork-and-patch procedure, assign a quarterly review owner. Budget a day for the pilot and a week for fleet consistency. External teams should replicate the pattern locally — a meta-package that pins your chosen toolchain — rather than take a dependency on private, zero-traction infrastructure.

Bottom line: Adopt only if you are inside the org and an owner with a refresh cadence exists. Pin to a commit, add it to the CI template, keep a documented fork path. Otherwise, treat it as a reference implementation of toolchain consolidation and move on.