# tsconfig bases: one tsconfig.json per runtime, and the Node 25 hole > The tsconfig/bases repository publishes npm packages that hold a single tsconfig.json tuned to one runtime, so a project extends a dependency instead of copying a config. The catalogue covers Node majors, Bun, Deno, Cypress and a dozen frameworks, and it has gaps a reader should know about before picking one. **tsconfig/bases** — Hosts TSConfigs to extend in a TypeScript app, tuned to a particular runtime environment - Repository: https://github.com/tsconfig/bases - Stars: 7,884 · Forks: 285 - Language: TypeScript - License: MIT - Published: 2026-09-22 · Updated: 2026-11-03 · Language: en - Canonical page: https://hysenlabs.com/projects/tsconfig-bases ## The base is a dev dependency, so compiler behaviour changes without a code diff The whole mechanism is two commands and one line of JSON. Pick a base, install it as a development dependency: ```sh npm install --save-dev @tsconfig/recommended yarn add --dev @tsconfig/recommended ``` Then point your project's tsconfig.json at it: ```json "extends": "@tsconfig/recommended/tsconfig.json" ``` The path matters. You extend the file inside the package, not the package name bare, which is the pattern repeated for every base in the catalogue. Yarn users get the same result with the second command. The consequence is about your dependency graph rather than your source. Because the base is an installed package, bumping it can change strictness, target and module resolution without a single line of application code changing. That is the benefit when a team reviews the base in one place, and the surprise when a transitive bump starts producing errors in a repository nobody touched. ## Node majors get one package each, and 25 is missing from the list The Node column is the widest part of the catalogue: separate packages for Node 10, 12, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24 and 26, plus `@tsconfig/node-lts` for the current LTS and `@tsconfig/node-ts` for Node with TypeScript, which the table labels as TS 5.8 only. There is a hole in that sequence. The list jumps from Node 24 to Node 26, so nothing in the catalogue targets Node 25. If you are on Node 25, the choice is between the 24 base, the 26 base and the LTS base, and none of them was written for your runtime. The Node 17 and Node 19 entries are a second signal worth reading. Odd-numbered Node releases are short-lived, and several of them (17, 19, 21 and 23) got their own package here, which means the cost of a runtime bump is a package swap rather than a hand edit to your config. ## One package per framework, and the README does not explain combining them Beyond Node, the catalogue covers Bun, Deno, Cypress, Create React App, Docusaurus v2, Ember, Next.js, Nuxt, QJSEngine, React Native, Remix, Svelte, Taro and Vite React, alongside the general `@tsconfig/recommended` and `@tsconfig/strictest`, and a `@tsconfig/bases` entry that points at the collection itself. Every one of those is a separate npm package with its own file under bases/, such as `bases/recommended.json`, `bases/bun.json`, `bases/create-react-app.json`, `bases/cypress.json` and `bases/deno.json`. A web app with Cypress for end to end tests and a bundler for the build touches two bases, so check the full README for how to combine them before picking one. ## Recommended and Strictest are a dial, and neither one's contents are in the README The catalogue offers two opinionated starting points that are not tied to a runtime, `@tsconfig/recommended` and `@tsconfig/strictest`, which tells you the maintainers think of strictness as something you turn up rather than something you settle once. The README entries shown give you the package name and the extends line, and the compiler options themselves live in the JSON under bases/. So the question that matters, which flags does this base actually set, is answered by opening `bases/strictest.json` or `bases/recommended.json`, not by reading the documentation. That is a reasonable division of labour for a repository whose product is the file, and it has a cost. You cannot evaluate a base from npm metadata or from a search result, and when a new base appears in the table you have no summary telling you whether it is stricter than the last one. ## No GitHub releases, so versioning follows the runtime it targets There are no GitHub releases for this repository. What the project says about versioning is that it targets the latest stable version of TypeScript, and that because the maintainers want to be consistent with the versioning of the target runtime, they cannot always do semver releases. For the framework-free and runtime-specific bases that means the package version is tied to the thing being targeted rather than to the base itself. A Node 22 base is versioned around Node 22, and when the runtime moves, the base moves with it. The practical reading is that your base version and your runtime version are two numbers you should upgrade together instead of independently. The last push to main was on 2026-09-24, and the licence is MIT in LICENSE.md. With no release tags to consult, the commit history and the npm version are the only record of what changed. ## The catalogue is generated, and one row's label disagrees with its link The README is assembled rather than written. An AUTO marker separates the hand written introduction and the table of TSConfigs from the long list of available configurations below it, and the repository layout explains why: bases/ holds the JSON, readme-extras/ holds the per-base extra sections, scripts/ and template/ hold the generation, and test/ holds the checks. One row in that table is a trap for anyone transcribing it. The QJSEngine entry is labelled `@tsconfig/qjsengine` while the link in the package column points at `@tsconfig/qtsengine` on npm. Copy the label and you install a package name the row never links to. The rest of the table is consistent, and every base follows the same three part shape: a heading with a link to its JSON file under bases/, an install snippet with the npm and yarn variants, and the extends line to paste into your own tsconfig.json. ## Conclusion tsconfig bases suits teams that want one reviewed place for compiler flags and a per-runtime upgrade path, and who are willing to read the JSON behind a base before extending it. Each base is published separately, and the compiler options live in bases/*.json. Before you commit, open the file you intend to extend under bases/, check the Node major it targets against the one you run, and install the base as a dev dependency so its version shows up in your lockfile. ## FAQ ### What is tsconfig bases for? It hosts tsconfig.json files that you extend in your own project, each tuned to a particular runtime environment, published as scoped npm packages under @tsconfig. The project describes itself as community owned and improved, and as Basically Definitely Typed for TSConfigs, and it targets the latest stable version of TypeScript. ### How do I use a tsconfig base in my project? Install the base as a development dependency with `npm install --save-dev @tsconfig/recommended`, or `yarn add --dev @tsconfig/recommended`, then add `"extends": "@tsconfig/recommended/tsconfig.json"` to your tsconfig.json. The extends path points at the file inside the package, not at the bare package name. ### Which Node version base should I extend? There are separate packages for Node 10, 12, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24 and 26, plus @tsconfig/node-lts for the current LTS and @tsconfig/node-ts for Node with TypeScript, labelled TS 5.8 only. Note that no package targets Node 25, so on that release you have to choose between the 24, 26 and LTS bases. ## Sources - [Issues](https://github.com/tsconfig/bases/issues) - [License: MIT](https://github.com/tsconfig/bases/blob/main/LICENSE) - [README](https://github.com/tsconfig/bases/blob/main/README.md) - [tsconfig/bases on GitHub](https://github.com/tsconfig/bases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tsconfig-bases