Skip to content

tsBuildInfoFile is not extendable. Add an alternative tsBuildInfoDir option #61794

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
6 tasks done
aweebit opened this issue Jun 1, 2025 · 0 comments
Open
6 tasks done

Comments

@aweebit
Copy link

aweebit commented Jun 1, 2025

πŸ” Search Terms

tsBuildInfoFile tsbuildinfo output directory

βœ… Viability Checklist

⭐ Suggestion

Add a tsBuildInfoDir config option for specifying the output directory for the .tsbuildinfo file.

πŸ“ƒ Motivating Example

tsconfig/
β”œβ”€β”€ tsconfig.base.json
β”œβ”€β”€ tsconfig.client.json
β”œβ”€β”€ tsconfig.config.json
└── tsconfig.server.json
tsconfig.json

With a project structure like this, there is no way to have the individual project configs (tsconfig.client.ts etc.) derive their tsBuildInfoFile setting from the base config (tsconfig.base.json). If we set tsBuildInfoFile to some custom value in the base config, the individual project configs all end up having the same output path for their .tsbuildinfo files, which is of course wrong, so we have no better option than to set tsBuildInfoFile for each of the projects individually.

The recently introduced ${configDir} template variable can't help us here since the config files are all located in the same folder. Even if they weren't, it still wouldn't give us enough flexibility.

One possible solution is to rely on the outDir option which also affects where .tsbuildinfo files are placed, but it's only fine if we don't mind them being placed beside other output files, or if there are no other output files because we are using noEmit.

What I suggest is adding a tsBuildInfoDir option for specifying the output directory for the .tsbuildinfo file as an alternative to tsBuildInfoFile. The process of determining how the file is placed within that directory should be identical to that of outDir / declarationDir, meaning that the config file's placement relative to rootDir should be replicated.

With the following tsconfig.base.json,

// tsconfig.base.json
{
  "compilerOptions": {
    "rootDir": "${configDir}",
    "outDir": "${configDir}/dist",
    "tsBuildInfoDir": "../node_modules/.tsbuildinfo",
    "incremental": true
  }
}

this would enable structure as complicated as this one:

client/
│── dist/
β”‚   │── index.js
│── index.ts
└── tsconfig.client.json
node_modules/
└── .tsbuildinfo/
    β”œβ”€β”€ tsconfig.client.tsbuildinfo
    β”œβ”€β”€ tsconfig.config.tsbuildinfo
    β”œβ”€β”€ tsconfig.server.tsbuildinfo
    └── tsconfig.tsbuildinfo
server/
│── dist/
β”‚   │── index.js
│── index.ts
└── tsconfig.server.json
tsconfig.base.json
tsconfig.config.json
tsconfig.json
vite.config.ts

Here is what I assumed about the other config files:

Click to expand
// client/tsconfig.client.json
{
  "include": ["**/*.ts"]
}

// client/tsconfig.server.json
{
  "include": ["**/*.ts"]
}

// tsconfig.config.json
{
  "compilerOptions": {
    "noEmit": true
  },
  "include": ["*.config.ts"]
}

// tsconfig.json
{
  "files": [],
  "references": [
    { "path": "./client/tsconfig.client.json" },
    { "path": "./server/tsconfig.server.json" },
    { "path": "./tsconfig.config.json" }
  ]
}

When both tsBuildInfoDir and tsBuildInfoFile are set, the latter could be interpreted as the desired file name rather than the path (the path is then ${tsBuildInfoDir}/${tsBuildInfoFile}).

πŸ’» Use Cases

  1. What do you want to use this for?
    β†’ Putting .tsbuildinfo files under node_modules/.tsbuildinfo so that they are not in the way, but I still get the advantages of incremental builds.
  2. What shortcomings exist with current approaches?
    β†’ The shortcomings of tsBuildInfoFile and outDir are described above.
  3. What workarounds are you using in the meantime?
    β†’ Setting tsBuildInfoFile for each project individually :(
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant