I don't know why the tsconfig.json is ignored even when the --project or -p option is specified.

Could you provide a repro for a situation where tsconfig is ignored?

Sure @andy-ms , but I mean, this is not even a bug. This behaviour is explicitly explained in the docs: When input files are specified on the command line, tsconfig.json files are ignored.

When you do tsc file.ts -p tsconfig.json you get:

The lines of code are pretty easy to find

I just can't understand why it's implemented this way.

Probably because no one's implemented it -- could you explain what the use cases are?

A pretty common practice is to have a pre-commit hook to compile only the staged files in your git project (It makes no sense to compile all the project).
If you try to create this hook that runs tsc over each staged file, you won't be able to use the tsconfig.json, as you are specifying some input files. @andy-ms

I have another use case for this. We have many projects that use typescript, and would like to reduce boilerplate and keep our typescript config in one place, so it can be uniformly applied across all our projects for consistency.

At the moment, there isn't a way to do this, since you can't specify both a glob of files to check, and an external path to a tsconfig.json file. The only workaround in the meantime is to copy/paste a tsconfig.json file into the root of every project and have it only contain an "extends" statement. This isn't the end of the world, but it's more boilerplate than we want - the fewer duplicate files across multiple projects we can have, the better.

This same goal is easily accomplished with TSLint, by using their --config option as well as a glob of files to lint. Is there any specific reason why it is disallowed by typescript itself? If not, I would be happy to take a stab at implementing it via pull request, just want to make sure its ok with maintainers.

related, but never considered #12958

I have a different use case that needs this as well. We have a pre-commit hook that does a quick type check (tsc -p tsconfig.json --noEmit). Currently it checks all the files specified in tsconfig.json, but it would be nice to only type check the files that were modified. We are currently using lint-staged to run linting tools on modified files, it would be great to only run the type check on the modified files too.

Like @brapifra said here, #27379 (comment), it's written in the docs that this should be possible, but it clearly isn't.

ref #22649, #13575

We have some questions for everyone in this thread

Long story short, the real problem we see is that people make a tsconfig.json, then run

tsc someFile.ts

and get garbage confusing errors because e.g. their tsconfig specifies target: ESNext and the error says something like "This is an ES5+ only API, change your target!". So we'd like to change that so that tsc always picks up a nearby tsconfig file, and provide an opt-out like --ignore-tsconfig for people who want to ignore it intentionally.

However, we're not sure what tsc someFile.ts means if there's a tsconfig present:

Question 1, do we:

• Overwrite the files setting
• Append to the files setting
• Prepend to the files setting (order rarely matters but sometimes does...)

Question 2:

• Are include and exclude still in play if there are some files specified on the commandline?

Question 3:

• What if someFile.ts was in the exclude list?

Thoughts?

Just my two cents:

A pretty common practice is to have a pre-commit hook to compile only the staged files in your git project (It makes no sense to compile all the project).

This use case seems problematic in general, since (AFAIK) TS needs to see your whole project for some things to work (e.g. const enum, declaration merging), unless you use isolatedModules which disables those features.

Question 1.

I would expect that we'll "Overwrite the files setting".

Question 3.

If we'll treat someFile.ts as file to override files list, then no problem here - from the docs:

Files included using "include" can be filtered using the "exclude" property. However, files included explicitly using the "files" property are always included regardless of "exclude".

Question 2.

IMO include should be ignored in this case.

I think there is cases when some modules pollute global scope and it might break the compilation (because not all modules require that modules with globals even if they use them), but I believe developers should import deps explicitly (via triple-slash directives or even import statements in this case).

So we'd like to change that so that tsc always picks up a nearby tsconfig file, and provide an opt-out like --ignore-tsconfig for people who want to ignore it intentionally.

@RyanCavanaugh So, we will not be able to pass path to the custom tsconfig via --project CLI option, right? I believe it's a use case as well and it would be good to cover it too.

Adding to the responses to the questions:

Question 1

• Overwrite the files setting

Question 2

• Ignore the include and exclude settings if files are specified on the commandline

Question 3

• Not applicable due to answer to Question 2

We would find value in this for writing an arcanist tsc linter.

Please find below the use-case and workaround in case you need it

The way arcanist external linters work is by specifying an includes regex and then running your linter on every file that matches it. Tried pretty much everything, unfortunately, right now the only way to make tsc <file> type-checking work and handle tsconfig.json seems to write a runner (a.k.a tsc spawner). It works by:

• specifying it to arcanist as the only file to type check in .arclint
• implementing an ArcanistExternalLinter whose sole responsibility is to call node runner.js
• runner will be called back as node <runnerPath/runner.js> <projectRoot> <runnerPath/runner.js>
• on runner.js, parse args and execute a spawn of tsc from project root, to type the whole codebase

This way, tsc is called once, type-checks the whole codebase and handles tsconfig.json as it should.

.arclint

{
  "linters": {
    "tsc": {
      "type": "tsc",
      // will call back linter just once, because we include just one file
      // it could be any existing file in filesystem, it doesn't matter
      "include": "/^linters\\/arc-tsclint\\/lint\\/linter\\/runner\\.js$/"
    }
  }
}

linters/tsc/lint/linter/runner.js

function main() {
  // We don't end up using currentFile, refactor when 27379 is fixed
  const [, , projectRoot, currentFile] = process.argv;

  const { stderr, stdout, status } = spawnSync("tsc", ["--noEmit", "--jsx", "react"], {
    cwd: projectRoot,
  });
  // Do arcanist-related stuff with stderr stdout and status
}

Overall a similar use-case as the one @brapifra noted, and we would like not to be reliant on such a hack.

One more use-case is serverless Lambda functions.

It is convenient to have many related Lambda functions together in one project with common tsconfig.js and common reused utility code reused by some but not all functions. Given that every Lambda function has only one entry point – its handler – we can compile only this handler file and will get only files required to run this given Lambda function.

This not only allows to put less files into function's code, but (which is more important) to update only those functions that really uses changed code.

Example

Given following project structure:

── src
    ├── handlers
    │   ├── a.ts
    │   ├── b.ts
    │   └── c.ts
    └── utils
        ├── ab.js
        └── bc.js

By executing following comands:

tsc --project . --outDir .aws-sam/build/AFunction src/handlers/a.ts
tsc --project . --outDir .aws-sam/build/BFunction src/handlers/b.ts
tsc --project . --outDir .aws-sam/build/CFunction src/handlers/c.ts

I want to get following transpiled results that uses settings from tsconfig.json:

.aws-sam/build/AFunction
└── src
    ├── handlers
    │   └── a.js
    └── utils
        └── ac.js
.aws-sam/build/AFunction
└── src
    ├── handlers
    │   └── b.js
    └── utils
        ├── ab.js
        └── bc.js
.aws-sam/build/CFunction
└── src
    ├── handlers
    │   └── c.js
    └── utils
        └── bc.js

Workaround

Generate one-off child tsconfig files that overwrites includes property as described at https://stackoverflow.com/a/44748041

echo "{\"extends\": \"./tsconfig.json\", \"include\": [\"src/handlers/a.ts\"] }" > tsconfig-only-handler-a.json
tsc --build tsconfig-only-handler-a.json

As https://github.com/AkhmadBabaev mentioned here #27379 (comment)

This worked for my project:

• tsconfig.json in project root
• use lint-staged.config.js
• omit -p tsconfig.json from tsc command

// lint-staged.config.js
module.exports = {
  "*.{js,ts,tsx}": "eslint --cache --fix",
  "**/*.ts?(x)": () => "tsc --noEmit",
};

I end up with esbuild so far.

My use-case is that we have converted a messy JS codebase to TS, so there are thousands of type errors. We want to go through and clean them up gradually, over time.

This means that we can't fail the build in CI for errors running tsc for the whole project.

It also means that running tsc --watch to diagnose and fix errors is pretty useless, you have to scroll through a bunch of errors unrelated to what you're working on.

I would love to be able to run a command like tsc --focus foo.ts bar.ts which will only show errors that occur in foo.ts or bar.ts (not even related errors in other files) – literally just filter the output of tsc by filepath.

My use-case has to do with Jest tests or npm run utility scripts invoked using ts-node. In my tsconfig.json I have some non-default compiler options set (e.g., "strict": true, "target": "ES2021", etc.), as well as the use of a dist output directory for the compiled JavaScript. When Jest tests or ts-node runs a single .ts file, it compiles with different options (i.e., the default options) than I have specified, and, worse, pollutes my src/** directory with a bunch of individual .js files (since, by default, the TypeScript compiler outputs the .js alongside the .ts source).

In my opinion, if a project takes the effort to define a project-wide tsconfig.json, those settings should be used whenever tsc is invoked. Command-line options to tsc at that point can/should override any conflicting setting in tsconfig.json.

This issue has hundreds of 👍 responses. In #27379 (comment) @RyanCavanaugh asked important questions about how it should work. In #27379 (comment) @timocov answered those questions, ("overwrite files setting") and got 9 👍 emojis and no negative responses. There was another response #27379 (comment) from @moopmonster which gave the exact same answer, and got 24 👍 emojis.

@RyanCavanaugh's question appears to be settled.

I speculate that a PR would be welcome that simply implemented the "overwrite files" approach.

It will be really nice if TypeScript team puts time on this issue.
I've read TypeScript's tsconfig.json behavior, it says TypeScript tries to seek every relative file that imports "ns" if you import "ns" as below.

import * ns from "mod"

And if the TS compiler finds files which import "ns", it automatically includes them in its compiling even though you don't want them to be type-checked. So to me, it sounds like TS will eventually look at extra files which might not be the ones you modified.

We want the option to tell the compiler to check the specific files, about TS grammar only, Not checking every referencing file! 😱

@moonformeli

We want the option to tell the compiler to check the specific files

This exists and is called noResolve