Danger JS: turning pull request etiquette into a Dangerfile

The problem Danger JS solves: conventions nobody enforces

Most teams have review rules that live in someone's head. A CHANGELOG entry is expected. A ticket link belongs in the description. Certain files should trigger a warning when they change. None of this is checked by a compiler, and reviewers forget under time pressure.

Danger JS exists to codify those norms. The README frames it as running after your CI, automating conventions around code review, and describes it as a way to "codify your team's norms, leaving humans to think about harder problems." That sentence is the whole pitch, and it is also the boundary: Danger JS is not replacing your test suite or your linter. It handles the rote checks that a human would otherwise repeat in every pull request.

The intended user is a team with a shared review culture and enough pull request volume that repeating the same comment twice a week becomes annoying. A solo maintainer on a low-traffic repository will spend more time writing a Dangerfile than the rules will ever save.

How Danger JS actually runs: CI, a Dangerfile, and a comment

The name is the mechanism. Danger JS is invoked after your CI job, reads a file called a Dangerfile, and reports violations back to the code review. The README lists the code hosts it works with as GitHub, BitBucket Server and BitBucket Cloud, and then a long list of CI systems: Travis CI, GitLab CI, Semaphore, Circle CI, GitHub Actions, Jenkins, Bamboo, Bitrise, surf-build, Codeship, Drone, Buildkite, Buddy.works, TeamCity, Visual Studio Team Services, Screwdriver, Concourse, Netlify, CodeBuild, Codefresh, AppCenter, BitBucket Pipelines, Cirrus CI, Codemagic and Xcode Cloud.

That CI list is the interesting part of the design. Danger JS does not care which runner executes it, because it is a command that runs in a shell. The package exposes several binaries, including danger, danger-ci, danger-pr, danger-local, danger-process and danger-runner, so the entry point changes depending on whether you are running inside CI, against a local pull request, or as a subprocess. The README's own development instructions use the pull request command directly:

yarn build; node --inspect distribution/commands/danger-pr.js https://github.com/danger/danger-js/pull/817

That line is the clearest illustration of the data flow available in the README: a pull request URL goes in, and the tool resolves the review metadata for it. The README also points to an architecture document at docs/architecture.md for the full picture, which is where a reader who wants the internals should go, because the README does not describe them.

The Dockerfile shows the CI entry point plainly. Its ENTRYPOINT is a single command, and the image is built with TypeScript pinned to a caret range, production dependencies installed with a frozen lockfile, and a symlink placed at /usr/bin/danger. In other words, the container is designed to be dropped into a pipeline and run as danger ci with no arguments.

Installing Danger JS and writing a first Dangerfile

The repository README is explicit that it is aimed at people working on Danger JS itself, not at end users: "you may be in the wrong place." End-user documentation is kept at danger.systems/js, with getting started, guides and a DSL reference. So the honest first step is to read those pages, because the README does not include the CLI flags for installation or the full DSL.

What the README does confirm is the package name. The npm package is called danger, and the repository ships a Dockerfile whose entrypoint runs the CI command. If you want the container path, the image is built from node:22-slim and exposes a danger binary via a symlink at /usr/bin/danger.

FROM node:22-slim AS base
WORKDIR /usr/src/danger
COPY package.json yarn.lock ./
RUN yarn install
COPY . .
RUN yarn run build:fast
RUN yarn install --production --frozen-lockfile
RUN chmod +x distribution/commands/danger.js
ENTRYPOINT ["danger", "ci"]

The Dockerfile in the repository does more than the trimmed excerpt above (it also swaps in a newer TypeScript and copies the distribution and node_modules into a final stage), but the shape is what matters: build, prune to production dependencies, run danger ci. For a pipeline that already has a Node image, installing the danger package and invoking the CI binary is the lighter route.

The repository itself contains several Dangerfiles as working examples: dangerfile.ts, dangerfile.lite.ts, dangerfile.circle.js and dangerfile.flow.js. Reading those is the fastest way to see what a rule looks like in practice, and they are real files rather than documentation samples. Beyond that, the README does not give the rule syntax, so treat the DSL reference at danger.systems/js as required reading before writing your own.

Where Danger JS is the wrong tool

Danger JS is not a linter and does not try to be one. If your problem is formatting, type errors or unused imports, ESLint or tsc already solve it, and the repository uses both (eslint for source files, tsc --noEmit for type checking). Adding Danger JS on top of that to check style would duplicate work and produce two comments about the same line.

The bigger limitation is scope of support. The README names three code hosts: GitHub, BitBucket Server and BitBucket Cloud. If your team reviews code somewhere else, the tool has no path to your review data, and no amount of Dangerfile writing fixes that. The CI list is broad, but the code host list is not, and the two are not interchangeable: CI is where the command runs, the code host is where the comment lands.

There is also a maintenance cost that the README does not discuss. A Dangerfile is code in your repository that runs in CI and depends on the review API. The README does not document rollback, and it says nothing about what happens when a rule starts failing for unrelated reasons. A team that cannot afford to keep a small script updated should not add one.

Finally, the README notes the project has a "pretty inactive Slack" and that discussion is kept in GitHub issues. That is a signal about where help comes from, not a defect, but it matters if you expect a responsive chat channel.

Danger JS compared with Danger Ruby and Danger Swift

The related searches around this project include Danger Ruby and Danger Swift, which is a fair reflection of how the ecosystem is organised: the same idea implemented for different language stacks. The difference is not in what the tools check but in what you write the rules in.

Danger JS runs on Node and its rules are TypeScript or JavaScript, which is why the repository contains .ts and .js Dangerfiles and why the package ships typings at distribution/danger.d.ts. If your repository is a JavaScript or TypeScript project, the rules live in the same language as the code, and contributors can edit them without learning anything new. That is the real argument for the JS implementation over the Ruby or Swift ones: not capability, but the language your team already reviews.

Against a generic CI script that greps the diff and posts a comment, the difference is the plugin system. The README describes "a comprehensive plugin system to share common issues," and points to a plugin development page at danger.systems/js/usage/extending-danger.html. A shell script that curls the review API will work until it needs to be shared, parameterised, or reused across repositories. Danger JS packages that reuse as a plugin, which is the reason to take on a dependency instead of writing twenty lines of bash.

Maintenance, releases and the MIT licence

The repository is not archived, and its last push was on 2026-08-28. The most recent release listed is 14.0.6 on 2026-08-27, with 14.0.5 and 14.0.4 earlier in the same month, while package.json on the default branch already reads 14.0.7. That pattern suggests releases are cut from tags rather than from the branch head.

The README describes the release process in unusual detail, and it is worth reading before you depend on a fast fix. Releases are triggered by pushing a version tag. Tag creation is restricted by a "Release tags" repository ruleset, so only the people on that ruleset's bypass list can ship a release. The documented bump command is npm run release -- patch --ci, which bumps package.json, commits, tags and pushes. Publishing to npm happens in a GitHub Actions workflow using npm's trusted publishing, with no NPM_TOKEN secret, and the publish job runs in an environment that only tags can deploy to. Changes under .github/workflows/ require an admin review via CODEOWNERS.

For an adopter, that means the upgrade path is ordinary npm version bumps, but the ability to get a patch out quickly sits with a small group. If your team needs to carry a local patch, the MIT licence permits it. The README states the project is MIT, which gives full access to the source and the right to modify it, and adds that you do not get access to deploy. That is a plain description of the licence terms, not legal advice, and anyone with specific questions should read the LICENSE file in the repository.

Editorial conclusion

Adopt Danger JS if your team already agrees on review conventions and wants them enforced as comments rather than in a wiki page; the npm package is named danger, and the README says end-user documentation lives at danger.systems/js. Do not adopt it expecting a general-purpose linter, and do not expect the repository README to walk you through installation, because it explicitly says you may be in the wrong place and redirects you. Verify first that your code host is one of the supported ones (GitHub, BitBucket Server, BitBucket Cloud) and that your CI is on the long list the README gives, then read the architecture doc before writing anything beyond a first Dangerfile.

Frequently asked questions

Official sources

1. danger/danger-js on GitHub
2. License: MIT
3. Project website
4. README
5. Releases