kcd-scripts: a personal build toolbox that exposes its own configuration

One dev dependency instead of a config file per tool

The stated problem is small and honest: the author does a bunch of open source and wants it to be easier to maintain so many projects. The solution is a CLI that abstracts away all configuration for his open source projects for linting, testing, building and more. It is distributed through npm, bundled with node, and installed as a devDependency of your project:

npm install --save-dev kcd-scripts

The package exposes a bin called kcd-scripts, and the manifest points that bin at dist/index.js, so the entry point is a single compiled file. The published files are the dist directory plus a small set of configuration entry points at the root, namely babel.js, config.js, eslint.js, husky.js, jest.js, prettier.js and shared-tsconfig.json, and those root files are what your project extends. The version field is 0.0.0-semantically-released, so the published version number comes from a release process rather than being written by hand.

The configuration is exported so you can override pieces of it

This is the part that distinguishes the tool from the one it is inspired by. Unlike react-scripts, kcd-scripts lets you specify your own configuration for things and have that plug directly into the way things work, and in addition it exposes its configuration so you can use it and override only the parts of the config you need. The stated benefit is editor integration for tools like ESLint, which require project-based ESLint configuration to be present to work. The pattern is to extend the shipped config from your own file. For ESLint, an .eslintrc with these contents:

{"extends": "./node_modules/kcd-scripts/eslint.js"}

and for babel, an .babelrc with:

{"presets": ["kcd-scripts/babel"]}

There is a caveat for the ESLint case, that for now you have to include an .eslintignore in your project until a linked eslint issue is resolved. The deliberate non-merging is also stated: kcd-scripts intentionally does not merge things for you when you start configuring things, to make it less magical and more straightforward, and extending can take place on your terms.

Jest configuration is merged by you, deliberately

The jest example is the clearest illustration of the no-magic approach, because it shows the merge happening in your file rather than inside the tool. You require the jest config from the package, assign it to module.exports, and then override what you need:

const {jest: jestConfig} = require('kcd-scripts/config')
module.exports = Object.assign(jestConfig, {
  // your overrides here

  // for test written in Typescript, add:
  transform: {
    '\\.(ts|tsx)$': '<rootDir>/node_modules/ts-jest/preprocessor.js',
  },
})

The TypeScript transform line is the part most people would copy, since it points at the ts-jest preprocessor inside node_modules with a rootDir relative path. Because the merge is explicit and lives in your file, there is no guessing about what the tool did to your settings, and the override survives an upgrade of the tool in a way an implicit merge might not.

TypeScript support is automatic, and mostly invisible

The TypeScript story is arranged so that most projects need to do nothing. If the tsconfig.json file is present in the project root and typescript is a dependency, the @babel/preset-typescript is loaded automatically when you use the default babel config that comes with kcd-scripts, and only if you customised your .babelrc file might you need to add @babel/preset-typescript to the presets section yourself. The tool also loads any .ts and .tsx files automatically, including the default entry point, so you do not have to worry about any rollup configuration. TypeScript definition files are generated automatically during the build script. The other automatic behaviour is the typecheck script: if you have one, normally set to kcd-scripts typecheck, it is run as part of the validate script, and validate is itself run as part of the pre-commit script. So the chain is typecheck inside validate inside pre-commit, and none of it needs to be wired by you.

The project dogfoods itself, which is how you learn the script names

There is no long list of commands, and that is deliberate. The documentation says the CLI is not planned to be documented or tested super duper well because it is really specific to the author's needs, and that you will find all available scripts in src/scripts. The way to learn what exists is to look at the project's own package.json, because the project dogfoods itself: the scripts there are of the form node src {scriptName}, and the manifest shows the actual set. The build is node src build, the format is node src format, the lint is node src lint, the test is node src test, there is a test:update variant that passes a --updateSnapshot flag, and the validate is node src validate. The package manifest also carries its own eslintConfig extending the kentcdodds and kentcdodds/jest configs, with a list of rules turned off, including no-console, no-nested-ternary, no-process-exit and no-useless-catch, and an eslintIgnore list of node_modules, coverage and dist. So the dogfooding runs in both directions, the tool configures itself and the tool is configured by itself.

The comparison with react-scripts, and the alternatives named

The inspiration is stated directly, and it is inspired by react-scripts. The difference in approach is the config exposure described above, and the reason for it is the editor integration problem, since react-scripts does not let you plug in your own configuration. The project also lists other solutions and invites pull requests to add more, with the caveat that this is again a very specific-to-the-author solution. Two are named. Rollpkg is a convention over configuration build tool for creating packages with TypeScript and Rollup. bebbi-scripts is described as like kcd-scripts but with tsc, with esm, cjs and types outputs, written in TypeScript, using yarn 3, with an init for package.json, yarn workspace support and extensibility for babel and storybook, and it explicitly does not support yarn pnp or npm. The author's own framing, that this is a very specific-to-me solution, is the sentence to keep in mind when comparing the three.

Small package, focused surface, and a stated release policy

The repository is small and the file list says what the tool is. There is a babel.js, a config.js, an eslint.js, a husky.js, a jest.config.js, a jest.js and a prettier.js at the root, a shared-tsconfig.json, an other directory, a src directory holding the scripts, and a .huskyrc.js. The husky file is how the pre-commit hook that runs validate gets wired, and the presence of a shared tsconfig at the root is what the TypeScript story in the previous sections depends on. The release history shows a major version bump from 15 to 16 in July 2024 and from 16 to 17 in February 2026, with 17.0.0 the current tag, and the version in the manifest is the semantically-released placeholder, so the published number comes from the release tooling. The last push was on 2026-05-13. The licence field on the repository says MIT, and the project asks for bug reports and feature requests through labelled issues, with a good first issue label for new contributors, and the feature requests are prioritised by votes.

Editorial conclusion

kcd-scripts suits a developer who wants one opinionated setup for lint, test, build and format across several projects and is willing to read the source of the tool rather than a documented API. It does not suit a team that needs a supported, stable tool with predictable behaviour across versions, because the author says plainly that he does not plan to document or test it thoroughly since it is specific to his own needs. Before adopting it, read the config files it exports, babel.js, eslint.js, jest.js and prettier.js, since that is where the actual behaviour lives, and check the Node version your project runs.

Frequently asked questions

Official sources

1. kentcdodds/kcd-scripts on GitHub
2. License: MIT
3. Project website
4. README
5. Releases