• Node.js 22 or later (see engines in package.json)
• npm (the project uses npm which produces a package-lock.json)

These are the npm scripts available when working on the CLI:

When the CLI is installed (all-contributors-cli) or run via npm run dev, these are the subcommands:

The project uses Vitest for testing. To run the test suite use:

npm test

This runs all tests without coverage. For coverage (thresholds and reports), use npm run test-coverage (see below).

If you want to run tests inside your editor and you use VS Code you can install the VitTest extension so tests are discovered and runnable through the VSCode test runner.

Test configuration is in vitest.config.ts.

The project enforces minimum code coverage thresholds in the Vitest config:

Tests will fail if coverage drops below these thresholds.

Run npm run test-coverage to generate coverage reports in the coverage/ directory:

• coverage/lcov-report/index.html — Interactive HTML report (open in a browser)
• coverage/lcov.info — LCOV format (used by Codecov)

The HTML report shows which files are covered by tests.

The project uses Codecov to track coverage over time and on pull requests.

• The workflow .github/workflows/test-deploy.yml runs tests with coverage and uploads coverage/lcov.info to Codecov via a codecov/codecov-action version.
• Coverage can appear in PR comments if enabled in the Codecov project.

Codecov is configured in .codecov.yml:

• Patch coverage is tracked (coverage of changed code in PRs)
• Project-level status checks are disabled
• PR comments are disabled

Codecov now required a token to upload coverage. Uploads use the repository secret secrets.CODECOV_TOKEN which is scoped to the all-contributors org and CLI repository.

You don't need a Codecov account to view coverage locally. Run npm run test-coverage and open the HTML report. Codecov is mainly for tracking trends and CI.

The project uses ESLint. Linting was migrated from kcd-scripts to a native ESLint setup that supports both CommonJS source files and ES module test files.

• Config: eslint.config.mjs
• Includes eslint:recommended, import rules, Vitest rules for test files, and project overrides

To check for issues you can run:

npm run lint

To auto-fix what ESLint and Prettier can fix you can run:

npm run lint-fix

This will fix many issues (e.g. Vitest aliases, unused eslint-disable directives, formatting). Some problems still need manual fixes (e.g. unused variables, tests without assertions).

Husky runs a pre-commit hook that lints and fixes staged files before each commit.

1. On git commit, Husky runs the pre-commit hook.
2. The hook runs lint-staged, which runs ESLint and Prettier on staged JavaScript files.
3. If that passes, the commit continues; if it fails, the commit is blocked.

If the hook gives you trouble, run npm run lint-fix manually, then try committing again. As a last resort you can skip the hook with git commit --no-verify; if you do, mention it in your PR so maintainers can help.

Configuration:

• The hook lives in .husky/pre-commit (it runs npx lint-staged).
• lint-staged is configured in package.json under the lint-staged field.
• Linting uses eslint.config.mjs.

• eslint — Core
• @eslint/js — Recommended rules
• eslint-plugin-import — Import/export rules
• @vitest/eslint-plugin — Vitest rules for test files
• globals — Node and Vitest globals for the lint environment

The build uses native Babel (migrated from kcd-scripts build). Key dependencies:

• @babel/core — Compiler (parse, transform, generate)
• @babel/cli — Runs babel src --out-dir dist
• @babel/preset-env — Compiles modern JS for the target (e.g. Node 22)
• @babel/runtime — Runtime helpers used by the transpiled code

npm run build

Output goes to dist/. To run the built CLI locally without publishing, use npm run start (runs dist/cli.js) or npm link from the repo root and then run all-contributors in another directory.

We use conventional commits for merged PRs. The Release Please GitHub Action automates the release flow: after merges to main, it opens a release PR with an updated changelog and version. A maintainer merges that PR when tests pass and the release is ready.

Release Please needs a GitHub token to open PRs. The repo uses the secret ALL_CONTRIBS_RELEASE_PLEASE_TOKEN (scoped to the all-contributors org and CLI repo). The same pattern could be extended to the app repo later if needed.

TBD -- this is not yet implemented but was implemented via circleci previously. We plan to create a release based process that will support release please and manual releases.