Laravel Slipway Laravel Package

Product Decisions This Supports

• Standardizing CI across Laravel services. Slipway generates and maintains pipeline definitions (GitHub Actions, CircleCI) plus a local runner (ci-local.sh, slipway:test-pipeline) from one declarative config. This turns "every repo has a slightly different YAML file" into a governed, upgradeable baseline — a platform-team lever rather than a per-repo chore.
• CI cost and cycle-time reduction. The Pest TIA support ('pest' => ['tia' => true] plus slipway:tia) lets teams adopt test impact analysis without hand-rolling baseline workflows. Relevant to any roadmap item framed as "cut CI minutes" or "speed up PR feedback."
• Trustworthy local verification. The 1.8 clean-worktree behavior (warn on dirty git status, and --clean cloning HEAD into a detached worktree) directly addresses false-pass risk — "it worked locally" becomes an auditable claim. This supports decisions about pre-merge gates and release readiness rather than being a pure DX nicety.
• Frontend build modernization decisions. build-assets presets (npm default, vite, bun) make a Vite or Bun migration a config change rather than a pipeline rewrite. Bun adoption is explicit and version-pinned (exact 1.2.21, checksum-verified install from GitHub Releases) — useful when scoping a "move to Bun" initiative with a defensible supply-chain story.
• Observability by default. The sentry step injects and uploads source maps with a locked @sentry/cli, deriving --release from SENTRY_RELEASE or the CI commit SHA. This makes "we can trace production errors to a commit" a pipeline property instead of a per-team discipline.
• Build vs. buy. The credible alternative is bespoke YAML plus a wiki page, or a heavier CI orchestration product. Slipway's scope is narrow and legible (Laravel/PHP, Pest, Vite/Bun, Sentry), which makes it a cheap buy and a poor thing to rebuild internally.
• Roadmap sequencing signal. 1.8's mix — hardened local runs, TIA, Bun, Sentry — suggests the package is maturing toward "opinionated default pipeline for Laravel teams" rather than broad CI portability. Plan adoption around GitHub Actions/CircleCI, not around eventual GitLab parity.

When to Consider This Package

Consider adoption when most of the following hold:

• The estate is Laravel/PHP, and pipelines are largely the same shape across repos (install, build assets, test, upload artifacts).
• You are on GitHub Actions or CircleCI — these are the generators with real depth in this release. Pest TIA baseline generation is explicitly GitHub-only.
• You have more than a handful of repos, or frequent CI drift and "works on my machine" incidents, so the maintenance saving amortizes the config-learning cost.
• You use Pest (TIA is Pest-specific) and/or Vite/Bun for assets, and optionally Sentry for error monitoring with source maps.
• You want local/CI parity as a policy — the dirty-tree warning and --clean worktree clone are only valuable if you actually intend local runs to be evidence.
• You can accept pinned tooling versions in the pipeline (e.g. Bun requires an exact version) and a config file as the source of truth for CI.

Look elsewhere when:

• The stack is not Laravel/PHP, or pipelines are dominated by non-PHP build graphs (polyglot monorepos, heavy native toolchains) where generated steps will be a minority of the job.
• You are standardized on GitLab CI, Buildkite, Jenkins, or Azure DevOps — this release gives no indication of coverage there, and TIA/asset presets assume the supported providers.
• You need full CI platform abstraction (dynamic matrices, complex caching graphs, reusable cross-language templates) rather than an opinionated Laravel pipeline.
• The org requires audited, vendor-supported release engineering with guaranteed migration paths; note the 1.8 behavior where removing tia does not delete an already-committed .github/workflows/tia-baseline.yml — cleanup is manual by design, which is a governance item to own.
• You have a single small repo where hand-written YAML is cheaper than adopting and tracking a generator.

How to Pitch It (Stakeholders)

To executives: This package replaces hand-maintained CI configuration with a generated, versioned baseline for our Laravel services. The business case is threefold: lower CI spend and faster PR feedback (Pest TIA adoption without custom tooling), fewer "passed locally, failed in CI" incidents (local runs now detect uncommitted changes and can re-run from a clean checkout of HEAD), and lower supply-chain risk on frontend builds (checksum-verified, exact-version Bun installs; locked Sentry CLI). It is a small, narrowly scoped dependency — not a platform migration — and it reduces the amount of bespoke infrastructure our engineers own.

To engineering: Adopt it as the single source of truth for pipeline steps, with per-repo config rather than per-repo YAML. You get a local runner that mirrors CI (ci-local.sh, slipway:test-pipeline), a --clean mode that clones HEAD into a detached worktree so uncommitted files can't fake a pass, opt-in Pest TIA that writes a baseline workflow and patches tests/Pest.php idempotently, build-assets presets for npm/Vite/Bun, and a Sentry step that uploads source maps with the release set from SENTRY_RELEASE or the commit SHA. Known constraints to plan around: TIA baseline generation is GitHub-only and the PR test command stays a full suite; removing tia leaves the committed baseline workflow in place, so deleting it is a deliberate, reviewable step; Bun requires an exact pinned version; and the vite preset without a script will warn because it falls back to npx vite build. Treat the generated workflows as reviewed artifacts — pin the package version, and re-run slipway:pin after upgrades.