is-ci

is-ci is a single-purpose npm package that answers one question: is this code currently running on a continuous integration server? Internally it re-exports the isCI boolean computed by the ci-info package, which inspects a wide range of CI-specific environment variables (Travis, GitHub Actions, CircleCI, GitLab CI, Jenkins, and dozens more) so is-ci itself never has to implement or maintain that detection logic.

The package ships two ways to consume that boolean: require('is-ci') for direct use inside application or script code, and an is-ci CLI executable that exits with status 0 when running in CI and 1 otherwise, making it usable directly in shell conditionals and npm scripts entries without writing any JavaScript at all.

What You Get

• Boolean CI Detection - require('is-ci') resolves to a plain boolean computed at require-time from ci-info’s isCI export, with no configuration needed.
• Zero-Config CLI Executable - installing the package exposes an is-ci binary (bin.js) that exits with code 0 on a CI server and 1 otherwise, so it can be used directly in shell &&/|| chains or npm scripts.
• First-Class TypeScript Definitions - index.d.ts re-exports the typed isCI value from ci-info, so TypeScript consumers get accurate typing without an extra @types package.
• Broad CI Provider Coverage via ci-info - detection logic is fully delegated to the ci-info dependency, so any CI provider ci-info supports (and any future ones it adds) is picked up automatically without a version bump of is-ci itself.

Common Use Cases

• Skipping interactive prompts - CLIs and scaffolding tools call is-ci to bypass or auto-answer interactive prompts when running unattended in CI.
• Conditional npm script behavior - package.json scripts branch on is-ci to run different test reporters, coverage uploads, or lint steps only in CI (e.g. "posttest": "is-ci || npm run lint").
• Guarding local-only developer tooling - setup wizards, git hook installers, or interactive migration tools skip themselves when is-ci reports true, since there’s no human present to respond.
• Gating publish/release steps - release and changelog tooling checks is-ci before performing steps that should only ever run from a CI runner, not a developer’s machine.

Under The Hood

Architecture is-ci has essentially no architecture of its own: index.js is a single-line re-export of ci-info’s isCI value, and bin.js is a four-line CLI wrapper that calls process.exit with 0 or 1 based on that same boolean. All actual environment-variable detection logic lives in and is fully delegated to the ci-info dependency — is-ci’s only responsibility is exposing that result through two different interfaces (a requirable value and a process exit code), which it does with no intermediate layers, no configuration, and no internal state.

Tech Stack The package is plain CommonJS ("type": "commonjs") with a single runtime dependency, ci-info (pinned to ^4.1.0), and no build step — index.d.ts is a hand-authored TypeScript declaration file rather than a tsc-compiled output. Dev-only tooling is limited to standard (a zero-configuration ESLint preset) for linting and clear-module for busting Node’s require cache between test assertions; a GitHub Actions workflow referenced in the README badge runs the test script on each push.

Code Quality The entire test suite is a single test.js file that uses Node’s built-in assert module (no external test framework) to check both branches of the boolean: it sets process.env.CI and asserts isCI is truthy, then clears CI-related environment variables and clears the module cache via clear-module to assert isCI is falsy afterward. Linting is enforced through the test npm script itself (standard && node test.js), and there is no explicit error handling anywhere in the source, since there is no fallible operation for it to guard — the surface area is a single synchronous boolean lookup.

What Makes It Unique is-ci is intentionally not novel: it introduces no new CI-detection technique of its own and exists purely as a documented, typed, dual-interface (library + CLI) convenience layer over ci-info’s existing detection logic. Its value is entirely in developer ergonomics — a one-line require() or a shell-friendly exit code — rather than in any original technical capability.