Peridot Concurrency Laravel Package

Product Decisions This Supports

• Test infrastructure investment (build vs. extend vs. buy): Informs whether to speed up the CI suite by adding a concurrency layer versus re-platforming the test stack. This package is an "extend" option only for teams already on Peridot.
• CI/CD cost and velocity: Faster spec runs translate directly into shorter PR feedback loops, higher deploy frequency, and lower compute minutes. A concurrent runner is a lever on engineering throughput, not a customer-facing feature.
• Developer experience roadmap: Signal for whether to prioritize "fast, reliable test feedback" as a quarterly engineering-enablement initiative versus de-prioritizing it.
• Technology standardization: Adopting this deepens lock-in to Peridot, a niche BDD framework relative to PHPUnit/Pest. This is a strategic "standardize vs. consolidate" decision, not just a tooling tweak.
• Build vs. buy for parallelism: Whether to write an in-house parallel harness versus consume an existing plugin. Here the "buy" (OSS adoption) carries hidden maintenance cost given low adoption.
• Roadmap risk: A 12-star, single-maintainer-style plugin with an unclear repository is a supply-chain and bus-factor signal for any dependency review.

When to Consider This Package

Adopt or trial only when all of the following hold:

• You already run Peridot for specs; the plugin is a pure drop-in speedup with no migration cost.
• Your suite is slow and embarrassingly parallel — spec files are independent, with no shared global state, DB fixtures, or ordering assumptions that break under concurrency.
• You can isolate the risk: pin the version, vendor it, and treat it as a timeboxed experiment with a fallback to serial runs.
• Your CI has spare parallel capacity (or cloud runners) so concurrency actually reduces wall-clock time rather than contending for resources.

Look elsewhere if:

• You are on PHPUnit, Pest, or Codeception — the de facto ecosystem. Use ParaTest (or Pest's built-in parallelism) instead: vastly larger community, active maintenance, and long-term support.
• You need guaranteed maintenance, security review, or SLAs — 12 stars, a low activity score (0.19), and an unresolved repository are disqualifying for anything critical-path.
• Your tests share mutable state (global singletons, shared databases). Concurrency will surface flakiness, not speed.
• You are considering consolidation — the strategic move is to migrate toward mainstream tooling, not to add a niche plugin to a niche framework.

How to Pitch It (Stakeholders)

To executives: "We can meaningfully cut CI wall-clock time and per-build compute cost by parallelizing our spec runs. The candidate is a small, MIT-licensed plugin. The caveat is maintenance risk — it has minimal community adoption, so I'd recommend a short, timeboxed pilot with a clear fallback, and treat it as an interim fix while we evaluate consolidating on the industry-standard PHP test stack."

To engineering leadership: "Low-effort experiment if we're already committed to Peridot: pin the dependency, gate it behind a config flag, and measure suite duration and flake rate before and after. If Peridot isn't a hard requirement, the higher-leverage decision is migrating to PHPUnit/Pest with ParaTest — bigger ecosystem, active maintenance, and no single-maintainer dependency. Either way, the real decision on the table is 'optimize the current stack' versus 'consolidate,' not 'adopt this plugin.'"

To engineering (practitioners): "Trial it behind a feature flag on a non-critical pipeline. Validate spec isolation, watch for race conditions and shared fixtures, and record time saved. If it's abandoned or breaks, we revert to serial execution — zero product impact."