Why does Vite create two TypeScript config files: tsconfig.json and tsconfig.node.json?

Question

I'm using Vite to create a new React + TypeScript project.

After creating the project, there are two TypeScript config files on the root folder: tsconfig.json and tsconfig.node.json. These are the contents of each one:

tsconfig.json

{
    "compilerOptions": {
        "target": "ESNext",
        "useDefineForClassFields": true,
        "lib": ["DOM", "DOM.Iterable", "ESNext"],
        "allowJs": false,
        "skipLibCheck": false,
        "esModuleInterop": false,
        "allowSyntheticDefaultImports": true,
        "strict": true,
        "forceConsistentCasingInFileNames": true,
        "module": "ESNext",
        "moduleResolution": "Node",
        "resolveJsonModule": true,
        "isolatedModules": true,
        "noEmit": true,
        "jsx": "react-jsx"
    },
    "include": ["src"],
    "references": [{ "path": "./tsconfig.node.json" }]
}

tsconfig.node.json

{
    "compilerOptions": {
        "composite": true,
        "module": "esnext",
        "moduleResolution": "node"
    },
    "include": ["vite.config.ts"]
}

Why do we need two?

What does the second one do?

Can I remove the second one?

Agriculturist

The tsconfig.node.json is just an extension of the tsconfig.json. Whether you can delete it, I would say not because that inlude of vite.config.ts only exists in the node.json – Fikes

useful link github.com/vitejs/vite/issues/2031 – Quart

github.com/vitejs/vite/issues/6828 – Quart

Answer 1

You need two different TS configs because the project is using two different environments in which the TypeScript code is executed:

1. Your app (src folder) is targeting (will be running) inside the browser
2. Vite itself including its config is running on your computer inside Node, which is totally different environment (compared with browser) with different API's and constraints

Thus there are two separate configs for those environments and two sets of source files that are defined by the include and exclude sections of these configs. Then there is one "master" config tsconfig.json which "rules them all"

And no, you probably don't want to delete the tsconfig.node.json but you can probably rename it to something like tsconfig.vite.json to make its purpose more clear. If you do, make sure to update "main" config accordingly

Coben

if we rename the tsconfig.node.json to tsconfig.vite.json, do we have to make any changes in the build script in package.json too? Otherwise how does vite recognise the renamed file? – Guglielma

@Guglielma TS compiler loads all the configs (at least in my current Vite setup there is one main tsconfig.json which references all other configs) and applies them to a files based on the exclude and include masks inside them... – Associationism

I'm noticing that there exists two artifacts vite.config.d.ts and vite.config.js when I build. Should I be checking both of these files into git? – Azotemia

@Azotemia You should for vite.config.js. – Ferryboat

I changed vite config file format from .ts to .mjs, so there is no need to build it e.g. there is no need for tsconfig.node.json. it seems to be working pretty fine, are there any advantages to keep config in .ts format and having yet another tsconfig in your repo? – Malignant

@Malignant It may not seem so but config files are still code so keeping it as ts files help you discover mistakes/typos/breaking changes faster – Associationism

I don't see any use of the tsconfig.node.json and there is no issue after I removed it from my react project. The reason I removed it is because it is not being used by my project and I don't like redundant files. – Information

I researched and found this thread because custom Rollup code in vite.config.ts was getting flagged for issues that were absolutely covered in tsconfig.json. GPT4 is unaware of how these files work. Removing tsconfig.node.json might later lead to build code not working, and with no tsconfig.node.json to document itself as a required component, you'll have no idea why because it looks like tsconfig.json is being used. So, leave the file, it's not redundant. My solution for now is to copy all tsconfig.json compilerOptions into tsconfig.node.json, adding "composite":true. – Grouty

Answer 2

As mentioned by Michal Levý, these are different configs for different environments.

You will notice that tsconfig.json includes a "references" key which points to an array that includes the tsconfig.node.json file. If you wish to change the filename of your vite tsconfig, be sure to update this reference.

Katz

I don't think the "references" key is necessary. From the docs, it looks like "references" is used to specify dependencies between projects, such as when one project uses types from another project. But there's not actually a dependency here. – Sorb

Answer 3

Adding on top of the already provided answers:

I did some digging and even checked the source code. The vite.config.ts seems to be transpiled and loaded directly using typescript API on each build/dev server restart so the reference to it from the "Project tsconfig" did not make much sense to me and then I found the following:

1. Apparently it was kind of a hack to not include specific types, that Vite is dependent on, to the actual Project you are building (for example @types/node to a browser based environment) - Vite GitHub issue: tsconfig.node.json should not be included in tsconfig.json references
   • Issue is, that this does not seem to be working any more
   • This introduces other issues when using project references or other libraries relying on specific typescript setup
2. That said, it might be used for different use cases in the future as seen in Vite GitHub pull request: use "solution" tsconfig so that vite.config.ts is type checked
   • One possibility is for compile time type checking as seen in the above PR

Bathos