andreapollastri/checkpoint
Checkpoint is a Laravel package for adding health checks to your application. Define custom checks, monitor critical services, and expose a lightweight endpoint so you can quickly confirm your app and its dependencies are running as expected.
Architecture fit. checkpoint is a Laravel/PHP developer-tooling package — an Artisan-command surface (checkpoint:github is named explicitly) that codifies project hygiene checks and scaffolds CI workflow files. It sits in the require-dev layer, not the runtime request path, so it does not alter application architecture, service boundaries, or data flow. Fit is high for teams already standardized on Laravel and GitHub Actions; it is a governance/consistency tool rather than a framework extension.
Integration feasibility. Low-to-moderate. It is a Composer dependency plus one or more published config/workflow stubs. The 1.2.1 change is a defect fix in an existing check (dependency CVE auditing) rather than a new subsystem, so it does not expand the integration surface — it closes a coverage gap. The one new external touchpoint is the Bun toolchain, and only conditionally.
What 1.2.1 actually changes (TPM reading).
bun.lock / bun.lockb with no package-lock.json was silently skipped by the NPM CVE audit — i.e. the check reported success while auditing nothing. That is the most important line in these notes: a silent pass is materially worse than a failure, because it produces false assurance in exactly the repos most likely to be early-adopting a non-npm toolchain.checkpoint:github now emits a Bun setup step when a Bun lockfile is detected. This matters because generated workflows that omit the toolchain setup are the classic source of "works locally, red in CI" first-run friction.Technical risk.
package-lock.json alongside bun.lock, workspaces, monorepos with nested lockfiles) are not described in the notes and may resolve to npm-first behavior. Worth validating before relying on it.bun audit behavior, exit codes, and advisory-source parity with npm audit are not characterized here. If the two report differently, teams will see inconsistent gate behavior across repos.Key questions for the maintainer / spike.
package-lock.json and bun.lock exist? Is there a config override to force a package manager?bun audit output parsed into the same normalized result model as npm audit, or is it passed through?Stack fit. Target profile: Laravel applications and packages on GitHub Actions, already using Composer, with at least one JavaScript dependency tree (Inertia/Vite, Livewire + Alpine, Filament, or a JS SDK). Teams with no JS dependency tree get no benefit from 1.2.1 specifically. Teams that have migrated — or are migrating — to Bun are the direct beneficiaries.
Migration path. Additive and reversible:
require-dev at ^1.2.1 (or the exact patch) in a single pilot repository.checkpoint:github, regenerate it and diff — expect a new Bun setup step. Review the diff before committing; generated files should be reviewed, not trusted blindly.No data migration, no downtime, no coordinated deploy. Reverting is a version pin.
Compatibility. Patch release; semver implies no breaking change. Two compatibility edges to verify rather than assume: (a) the generated workflow stub now references a Bun setup action, which introduces a third-party action into the CI supply chain and a version pin to track; (b) environments where Bun is intentionally not installed will now surface a warning on every audit run — noisy for repos that never intend to use Bun, so confirm the detection logic does not misfire on stray lockfiles.
Sequencing.
Maintenance. Low. Dev-only dependency, patch-level upgrade, one config file and possibly one generated workflow file to keep in sync. The ongoing cost is the regenerated-workflow drift: each checkpoint:github run can rewrite CI YAML, so teams that hand-tune their workflows need an explicit rule about which file is authoritative. Budget a small recurring review of generated-file diffs, not a large one.
Support. Support surface is narrow — Artisan commands, a config file, and CI YAML. The realistic support tickets are "the audit warned about Bun on a repo we didn't think used Bun" (detection/stray lockfile) and "the generated workflow fails at the Bun setup step" (action version or runner image). The issue-linked fix history suggests maintainer engagement, but this is a single-maintainer-shaped project: treat bus factor as the primary support risk and keep the pin-and-revert escape hatch documented.
Scaling. Scales well. Checks execute per-repository in CI, so cost is linear in repo count × CI minutes, not a shared-service bottleneck. Two scaling caveats: (a) adding a Bun setup step adds setup time to every affected job — measurable but small; (b) monorepos with many nested lockfiles may trigger multiple audits or ambiguous detection, which is where the linear model gets inefficient. Confirm behavior before applying org-wide.
Failure modes.
Ramp-up. Very low. Consumers need no new skills — they run a command and read a report. The genuine ramp-up is policy, not tooling: agree who owns generated workflows, whether audit findings block merges, and what the org's JS package-manager story is (npm-only, or npm-plus-Bun). That conversation takes longer than the install and is the actual work item for a TPM here.
TPM recommendation. Adopt 1.2.1 — it fixes a false-negative in a security-adjacent check, which is a strictly better default than the prior behavior, at patch-level risk. Treat it as a correctness fix, not a new capability; do not re-baseline roadmap or compliance claims on it. Before org-wide rollout, get answers on audit fail-behavior and package-manager precedence, and set an explicit policy on warn-vs-block. Note the evidence base for this assessment is a single patch release note with no prior assessment on file, so confidence is moderate on the fix and low on the surrounding package behavior — the pilot step is the cheapest way to close that gap.
How can I help you explore Laravel packages today?