this will be very helpful in a monorepo situation, instead of installing different config for vite, node, next ....
just a single package with all the configs.

Recent commits added "tsconfig/next-strictest" and the documentation claims you can install it as so:
https://github.com/tsconfig/bases#nextjs-tsconfigjson

However, it is not actually published to NPM.
https://www.npmjs.com/search?q=%40tsconfig%2Fnext-strictest

opposite of strictest

Could be discovered here: https://stackoverflow.com/questions/59506821/starter-tsconfig-json-that-is-the-most-laxed-loose-for-pure-javascript-projects

Issue

Current moduleResolution value is "node". This doesn't seem to support "exports" in package.json.

Possible Solution

Change moduleResolution to "Node16" seems appropriate. A quick test overriding the value after extending this configuration seems to solve the issue.

After v19.0, now v19.1 of Node.js is out.

Looks like this is the default: https://angular.io/guide/typescript-configuration

{
  "compileOnSave": false,
  "compilerOptions": {
    "baseUrl": "./",
    "outDir": "./dist/out-tsc",
    "sourceMap": true,
    "declaration": false,
    "downlevelIteration": true,
    "experimentalDecorators": true,
    "moduleResolution": "node",
    "importHelpers": true,
    "target": "es2015",
    "module": "es2020",
    "lib": [
      "es2018",
      "dom"
    ]
  }
}

https://www.npmjs.com/package/@tsconfig/nodeLts-strictest-esm

typescript @ alias not work

Cannot find module '@/components/' or its corresponding type declarations.ts

tsconfig.json

{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": false,
    "jsx": "react",
    "outDir": "./dist/",
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"],
      "@/components/*": ["./src/components/*"],
    },
  },
  "include": [
    "./src/**/*",
  ]
}

I daily run Node 16 so it is natural that when creating new projects, one of the first things I do is yarn add --dev @tsconfig/node16.

This does however present an issue; the node16 tsconfig contains es2021 as it's "target" and "lib" which causes TypeScript to scream at me both within my IDE (VS Code) and upon compiling my project.

I assumed I had an old version of typescript installed or similar but upon checking the Official Documentation, I have discovered that es2021 is not actually a valid property.

Should this become ESNext instead until ES2021 is supported?

Also, as a side note, all of the configs currently specify the ECMA version in lowercase (es2020), whilst the documentation uses uppercase (ES2020); these should probably be updated to follow the documentation.

Deno base is not published to npm according to https://www.npmjs.com/search?q=%40tsconfig.

With Internet Explorer 11 support ended what does this mean for what version of ES we can target for web applications created through create-react-app?

I am looking forward to being able to use async generators, etc. without high transpilations once they are natively supported by all of my target platforms. 😄

There's some "prior art" in terms of reusable configs: https://github.com/mightyiam/tsconfigs

I like the fact that it has different environment use cases.

Is this something that this project could also do?

instead of being clever with git, which seems to be unreliable - then maybe the daily deploy process should download the tsconfig JSON run prettier on both of them and compare the strings. If different, deploy.

This could simplify their tsconfig's drastically.

"lib": ["es2022"] does not appear to be a valid value, https://www.typescriptlang.org/tsconfig#lib - is this correct?

NestJS is popular Node.js/TypeScript framework.

Based on the list of available and omitted polyfills, a base config could be made for Next.js projects. This would make sure that no compatibility issues arise during runtime in older browsers.

I want to import json file and use NodeNext module configurations:

For Node users using my lib I need to add assert { type: 'json' }
But when I use "module": "NodeNext", an import like that:

import isracardCardsTransactionsList from '../schemas/isracardCardsTransactionsList.json' assert { type: 'json' };

I get an error: error TS2836: Import assertions are not allowed on statements that transpile to commonjs 'require' calls.

When I go back to "module": "ESNext" it works.

What do you think would be the right configurations?

P.S. this is the repo: https://github.com/Urigo/israeli-bank-scrapers-modern-schemas

tsconfig.json files will soon support arrays inside the "extends" key:
microsoft/TypeScript#29118

I'd imagine this will simplify this project a lot, and make creating typescript configurations much more expressive.

I believe it may be best to re-imagine tsconfig/bases given this new TS feature. I can't imagine migrating from the non-array based setup would be hard. Existing packages would still exist as published, but wouldn't receive any new updates (do they need to be updated?).

_{hype train: https://twitter.com/DevinRhode2/status/1602790036050681858}

For non-greenfields projects, it would be useful to allow the mixing of JavaScript and TypeScript as a codebase is moved from one to the other. tsconfig does allow for this via allowJs and checkJs

For example:

{
  "extends": "@tsconfig/recommended/tsconfig.json",
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true,
    "outDir": "build"
  },
  "includes": ["src"]
}

{
    "extends": "../../tsconfig.json",
    "include": [
        "**/*.ts"
    ],
    "exclude": [
        "node_modules", 
        "build"
    ],
    "compilerOptions": {
        "baseUrl": ".",
        "rootDir": ".",
        "outDir": "build/",
        "plugins": [
            {
                "name": "@rollup/plugin-typescript"
            },
            {
                "name": "@rollup/plugin-json"
            }
        ]
    }
}

bumps into the following build error:

[!] TypeError: Module "file:///usr/src/Node.JSRestAPI/src/core/tsconfig.json" needs an import assertion of type "json"
TypeError [ERR_IMPORT_ASSERTION_TYPE_MISSING]: Module "file:///usr/src/Node.JSRestAPI/src/core/tsconfig.json" needs an import assertion of type "json"
    at new NodeError (node:internal/errors:393:5)
    at validateAssertions (node:internal/modules/esm/assert:82:15)
    at defaultLoad (node:internal/modules/esm/load:84:3)
    at nextLoad (node:internal/modules/esm/loader:164:28)
    at ESMLoader.load (node:internal/modules/esm/loader:603:26)
    at ESMLoader.moduleProvider (node:internal/modules/esm/loader:459:22)
    at new ModuleJob (node:internal/modules/esm/module_job:63:26)
    at #createModuleJob (node:internal/modules/esm/loader:478:17)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:436:34)
    at async ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:78:21)

I have set "resolveJsonModule": true, in top-level tsconfig.json

Self-explanatory; the following:

npm install --save-dev "@tsconfig/node16-strictest"

results in:

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@tsconfig%2fnode16-strictest - Not found
npm ERR! 404
npm ERR! 404  '@tsconfig/node16-strictest@*' is not in this registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\user\AppData\Local\npm-cache\_logs\2022-02-15T00_39_37_612Z-debug.log

Are these not published to npm, or is extending them via node_modules going to be the intended usage?

It seems it would be quite helpful to have a base that maps to node lts (at current 16.13.0 to 16.X). An example were it could be used in in Github Actions where one can always target node lts as follows.

name: Setup
description: Setup pnpm, Node and install dependencies
runs:
  using: composite
  steps:
    - name: Install pnpm
      uses: pnpm/action-setup@v2
      with:
        version: 7

    - name: Install Node.js
      uses: actions/setup-node@v3
      with:
        node-version: "lts/*"

    - name: Install NPM packages
      run: pnpm install
      shell: bash

The key here is node-version: "lts/*" which as one would guess will always be the latest lts. Therefore in our code it would be nice to create a base tsconfig that extends from a tsconfig base current lts. At the time of this issue the current lts is 16.18.0 so one could either copy the current node-16 bases and start new set or maybe script a way to publish whatever the current lts mapping is and publish as node-lts then there would be only one set to manage.

Maybe puppeteer is just node scripts, but maybe it's not quite that simple?

Could definitely take advantage of top level await

Would love to see nextron into tsconfig.json

https://www.npmjs.com/package/nextron

Reproduce:

npx react-native init MyApp --template react-native-template-typescript
cd MyApp
yarn add --dev @tsconfig/react-native
# update 

tsconfig.json

{
  "extends": "@tsconfig/react-native/tsconfig.json"
}

The issue:

yarn why v1.22.17
[1/4] Why do we have the module "@types/node"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "@types/[email protected]"
info Reasons this module exists
   - "@jest#types" depends on it
   - Hoisted from "@jest#types#@types#node"
   - Hoisted from "jest-haste-map#@types#node"
   - Hoisted from "jest-util#@types#node"
   - Hoisted from "jest-worker#@types#node"
   - Hoisted from "jest#@jest#core#@types#node"
   - Hoisted from "jest-haste-map#@types#graceful-fs#@types#node"
   - Hoisted from "jest-haste-map#jest-serializer#@types#node"
   - Hoisted from "jest#@jest#core#@jest#console#@types#node"
   - Hoisted from "react-native#@jest#create-cache-key-function#@jest#types#@types#node"
   - Hoisted from "jest#@jest#core#jest-runner#@types#node"
   - Hoisted from "jest#@jest#core#jest-watcher#@types#node"
   - Hoisted from "jest#@jest#core#jest-runner#@jest#environment#@types#node"
   - Hoisted from "jest#@jest#core#jest-runtime#@jest#fake-timers#@types#node"
   - Hoisted from "jest#@jest#core#jest-config#jest-environment-jsdom#@types#node"
   - Hoisted from "jest#@jest#core#jest-config#jest-environment-node#@types#node"
   - Hoisted from "jest#@jest#core#jest-config#jest-jasmine2#@types#node"
   - Hoisted from "jest#@jest#core#jest-runtime#jest-mock#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro-core#jest-haste-map#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro#jest-haste-map#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro-core#jest-haste-map#@jest#types#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro#jest-haste-map#@jest#types#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro-core#jest-haste-map#jest-serializer#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro#jest-haste-map#jest-serializer#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro-core#jest-haste-map#jest-util#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro#jest-haste-map#jest-util#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro-core#jest-haste-map#jest-worker#@types#node"
   - Hoisted from "react-native#@react-native-community#cli#@react-native-community#cli-plugin-metro#metro#jest-haste-map#jest-worker#@types#node"
info Disk size without dependencies: "1.75MB"
info Disk size with unique dependencies: "1.75MB"
info Disk size with transitive dependencies: "1.75MB"
info Number of shared dependencies: 0

Following the addition of the "strictest" config there is now an issue for users who want to use "strictest" and another base from this repo (ex. "node16").

Could an additional script be added to generate combined bases?

ex. given the input of

[
	["strictest", "node16", "esm"],
	["strictest", "node16"]
]

output the bases

• strictest-node16-esm/tsconfig.json
• strictest-node16/tsconfig.json

Where "strictest-node16-esm` is defined as "esm" (a potential new base, see #76) extends "node16" extends "strictest".

https://www.npmjs.com/package/@tsconfig/svelte

Hello! Thanks for this great package.

I have an project that uses @tsconfig/[email protected]. After upgrading it to @tsconfig/[email protected], it fails to compile.

ERROR in D:\Devel\Projects\devlog\devlog-web\app\index.ts
./app/index.ts 3:16-30
[tsl] ERROR in D:\Devel\Projects\devlog\devlog-web\app\index.ts(3,17)
      TS2307: Cannot find module './App.svelte' or its corresponding type declarations.
ts-loader-default_e3b0c44298fc1c14

Here's the diff between the @1.0.11 and the @2.0.1. As you can see, the types property is gone.

--- a/1.0.11.json
+++ b/2.0.1.json
@@ -16,8 +17,6 @@
       enable source maps by default.
      */
     "sourceMap": true,
-    /** Requests the runtime types from the svelte modules by default. Needed for TS files or else you get errors. */
-    "types": ["svelte"],

     "strict": false,
     "esModuleInterop": true,

Is it intended or bug? Should I stick to @1.0.10?

I'm wonder it might help but below are the packages I'm using.

• [email protected]
• [email protected]
• [email protected]
• [email protected]

Thank you.

EDIT

After some searching, I found that it's intended and a workaround is already mentioned #55 . And I think it should be documented somewhere. I'm sorry for bothering.

While it is relatively easy to find the changes in the git history, it would be great to have a convenient changelog.
Also, having a short rationale for each change would be really awesome!

Since this repo has a base for react-native, it might make sense to have one for react web?

Using npx create-react-app my-app --template typescript you end up with the following config, could be a good start for a base:

{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react"
  },
  "include": [
    "src"
  ]
}

Could be up to ES2017?

https://caniuse.com/#compare=firefox+76,chrome+81,safari+13.1,opera+68,ios_saf+13.4,and_chr+81,and_ff+68,and_uc+12.12,samsung+11.1&compare_cats=JS,JS%20API

Today there isn't a JSON5 or JSONC parser for deno - which means I can't do the runtime edits (without shelling out like I do in make-monaco-builds

Background:
I created a new Node project and wanted to use @tsconfig/node14 base in my tsconfig. As EcmaScript modules are fully supported in Node 14 I began using the ESM syntax and got a runtime error because the base specifies CommonJS as module system.

I got the same error as this Stack Overflow post.

node server/
file:///C:/Users/stianahj/Documents/wishlist/server/dist/app.js:5
Object.defineProperty(exports, "__esModule", { value: true });
                      ^

ReferenceError: exports is not defined in ES module scope
This file is being treated as an ES module because it has a '.js' file extension and 'C:\Users\stianahj\Documents\wishlist\server\package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
    at file:///C:/Users/stianj/Documents/wishlist/server/dist/app.js:5:23
?[90m    at ModuleJob.run (internal/modules/esm/module_job.js:169:25)?[39m
?[90m    at async Loader.import (internal/modules/esm/loader.js:177:24)?[39m
?[90m    at async Object.loadESM (internal/process/esm_loader.js:68:5)?[39m

Discussion point: Since ESM is a stable feature in Node 14, should ESM also be the module system in the @tsconfig/node14? I think it makes sense. Also wrote something in a comment on the docs microsoft/TypeScript-Website#1366 (comment).

Lastly, I can add that overriding the base works by simply specifying the field you want to override in your own tsconfig.json. One can still use the base, so this is just a discussion about what should be the default.

When extending my TypeScript configuration using node 14 I'm getting an error when using VS Code debugger.

File '@tsconfig/node14/tsconfig.json' not found.

tsconfig.json file contents:

{
  "extends": "@tsconfig/node14/tsconfig.json",
  "compilerOptions": {
    "esModuleInterop": true,
    "noEmitOnError": true,
    "outDir": "dist",
    "removeComments": false,
    "resolveJsonModule": true,
    "rootDir": ".",
    "sourceMap": true,
  },
  "include": [
    "**/*.ts",
    "**/*.spec.ts"
  ],
  "exclude": [
    "node_modules",
    "dist/*"
  ]
}

package.json file content excerpt:

  "devDependencies": {
    "@graphql-codegen/cli": "^2.2.0",
    "@graphql-codegen/introspection": "^2.1.0",
    "@graphql-codegen/typescript": "^2.2.2",
    "@graphql-codegen/typescript-resolvers": "^2.2.1",
    "@tsconfig/node14": "^1.0.1",
    "azure-functions-core-tools": "^3.0.3734",
    "typescript": "^4.4.3"
  }

Package listing:

├── @tsconfig/[email protected] 
└─┬ [email protected]
  └── @tsconfig/[email protected]  deduped

{
  "extends": "@tsconfig/node10",
}

resolves to "@tsconfig/node10/tsconfig.json" by default in the compiler, but cmd + clicking doesn't work in the editor. Need to add support to TS before we can drop the final /tsconfig.json in the references.

See: https://www.npmjs.com/search?q=%40tsconfig

In Readme, npm install --save-dev @tsconfig/node16 example is provided, but @tsconfig/node16 is not published to npm.

For a nodejs project, I want to exclude DOM library type definitions. I use the following compiler option

{
  "compilerOptions": {
    "lib": ["es2019", "es2020.promise", "es2020.bigint", "es2020.string"],
    "target": "es2019",
    "module": "commonjs",
    "skipLibCheck": true,
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "allowJs": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "inlineSourceMap": true,
    "importHelpers": true,
    "alwaysStrict": true,
    "strict": true,
    "outDir": "build",
    "forceConsistentCasingInFileNames": true,
    "esModuleInterop": true,
    "typeRoots": ["./node_modules/@types", "./typings"],
    "baseUrl": ".",
    "paths": {
      "#root/*": ["./*"]
    }
  },
  "include": [
    "src/**/*",
    "__tests__/**/*",
    "config/**/*",
    "scripts/bundle-test.ts"
  ],
  "exclude": ["node_modules"]
}

I have not included "dom" in the lib options but I am still getting the types from [VS Code installation folder]/code/resources/app/extensions/node_modules/typescript/lib/lib.dom.d.ts] being included in my workspace. This have lead to multiple run time errors. In particular, the parent object from Window is being included (declare var parent: Window;. Is there a way to avoid it?

I'm currently exploring how to get rid of the "types": ["svelte"] entry in Svelte's tsconfig base. Doing this would be a breaking change, @tsconfig/svelte would need to be bumped to 2.0.0 if that (not-yet-created) PR would get merged. Is this possible with the current infrastructure? If so, how to accomplish it? If not, how would adding this look like?

Hi there

I Love the idea of sharing tsconfig file. Great idea.
I can see in the recommended tsconfig.json that skipLibCheck is set to true.

Do we really want to enforce that behaviour ?
As I can see here:

• https://www.typescriptlang.org/tsconfig#skipLibCheck
• https://stackoverflow.com/questions/52311779/usage-of-the-typescript-compiler-argument-skiplibcheck
• https://www.reddit.com/r/typescript/comments/aa3ui7/question_why_skiplibcheck_true_is_not_the_default/

There is pros in day to day coding but cons in the long term

Basically @tsconfig/recommended but with all possible pedantic flags turned on

Hey!

First of all, thank you for this amazing project!

➜ npm install --save-dev @tsconfig/next

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@tsconfig%2fnext - Not found
npm ERR! 404 
npm ERR! 404  '@tsconfig/next@*' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/hnordt/.npm/_logs/2021-06-06T17_07_42_807Z-debug.log