Typescript: [Feature Proposal] How to use tsc with compilerOptions from tsconfig.json?

[cookiengineer]

The tsc binary does not allow to use a tsconfig.json with files as arguments in combination.

Why is this the case? Is there any reason for that? It would make things so much easier for third-party linting processes (such as the one in syntastic / VIM) as they simply could respect the identical config as the build setup.

The problem here is diversion of user-based config (flags for tsc to lint files that are setup in the IDE's config) to project-based config. If a project uses different flags (e.g. --module) you cannot migrate IDE configs easily to the JSON config in the tsconfig.json.

tsc --project /path/to/my/project/with/tsconfig.json/ somefile.ts someotherfile.ts

The above example is not possible because of the following error message:

error TS5042: Option 'project' cannot be mixed with source files on a command line.

Is there any chance the tsc binary can get a flag that can respect the tsconfig.json file's compiler options?
In an optimum world, someone could use something like this:

tsc --config /path/to/tsconfig.json somefile.ts someotherfile.ts;

[mhegazy]

The tsc binary does not allow to use a tsconfig.json with files as arguments in combination. Why is this the case?

cause it is ambigious to do it other wise. project file can specify input files as well. overriding seems unexpected, augmenting seems confusing.

The problem here is diversion of user-based config (flags for tsc to lint files that are setup in the IDE's config) to project-based config. If a project uses different flags (e.g. --module) you cannot migrate IDE configs easily to the JSON config in the tsconfig.json.

You can pass additional options on the commandline along with tsconfig.json

tsc --project /path/to/my/project/with/tsconfig.json/  --m AMD --noEmit

these options override the ones in the config file.

Is there any chance the tsc binary can get a flag that can respect the tsconfig.json file's compiler options?
In an optimum world, someone could use something like this:

unlinkely

[cookiengineer]

Why not offer something like a --config flag that respects the same settings, and this one denies augmenting it with further flags so it has the identical behaviour as a tsc call in a folder?

[mhegazy]

there are too many ways already to call the compiler. tsconfig.json, response files, commandline, with no arguments. every time a new mode is added there is more complexity on the user side and on the code side.

I am not sure i understand your scenario, why not just use tsc --watch and list your input files in your tsconfig.json?

[basarat]

there are too many ways already to call the compiler.

I agree :rose:. Letting tsconfig.json drive the files will also help your IDE (a key selling point / value proposition of TypeScript) :rose:

[aluanhaddad]

@basarat Very true, and even loader plugins use it these days. tsconfig.json FTW!

[cookiengineer]

I don't know if I was unclear. I was proposing to _prefer_ tsconfig.json to use it for all hinting and linting modes tsc is used for.

BUT in order to not compile down hundreds/thousands of files all the time (based on the tsconfig.json) it is necessary to have something like tsc --respect /path/to/tsconfig.json file1.ts. If that is not possible, you are introducing a shitload of compile time for each linting process in every IDE (that has not already fixed it themselves and made an own linter).

Okay, let's put it in a question:

Given you use tsc to lint files because that's what VIM and other editors do. How do you stay sane with having multiple projects with multiple tsconfig.json compiler options for each project and still be able to lint each project's files on their own without compiling down the complete project!?

Is that possible? Yes/No?

[basarat]

If that is not possible, you are introducing a shitload of compile time for each linting process in every IDE

Not quite. IDEs can be super smart and just get emit for a single changed file. atom/vscode/alm/vs all do this. Even gulp (with gulp-tsb) does this. They all essentailly create a Project and then get to ask the language service to get the emit for a single file.

Note: You cannot lint the whole project by just giving a single file on the command line. You _will get in situations when the project has errors due to changes in a file but you don't get any notification_ :rose:

An example where a change in file a can cause an error in file b:

[nomaed]

Sorry for bringing up this old-ish and closed issue, but @mhegazy wrote:

You can pass additional options on the commandline along with tsconfig.json
tsc --project /path/to/my/project/with/tsconfig.json/ --m AMD --noEmit
these options override the ones in the config file.

If there are CLI options that override tsconfig.json, why not saying that explicit files that are provided in CLI are overriding tsconfig.json as well?
You can treat incoming CLI files as if they are "files": [ ...args ] in tsconfig.json, for example.

[aluanhaddad]

@nomaed it's still ambiguous because it could mean

1. add the specific files to the compilation context
2. override the files value of compilerOptions
3. or add a files property to compilerOptions.

[mhegazy]

as @aluanhaddad mentioned. the merging semantics are not clear.

[timsuchanek]

So how to accomplish using the compilerOptions in the tsc command?
I'm just trying this:

tsc src/Component.tsx --outDir ./tsbuild

even this doesn't work:

tsc --project tsconfig.json src/Component.tsx --outDir ./tsbuild

error TS5042: Option 'project' cannot be mixed with source files on a command line.

So I have to type in all compiler options by hand additionally to the tsc command?

[Dejavs]

timsuchanek +1

[aluanhaddad]

Have you looked into configuration inheritance?