TSConfig compilerOptions should have a way to disable defaults

[giseburt]

Edited: Previously described a possible solution without describing the problem

Problem

Currently TypeScriptProject always merges in a set of default compilerOptions. Of course you can override any of them, so if you want none of them (such as when you're using extends instead to provide compilerOptions from another file) you have to provide overrides for everything that is set in the defaults with undefined.

When using compilerOptions in combination with extends we have three scenarios:

1. Use the default compilerOptions, maybe with a few overrides (current state)
2. Would like to use extends to set the compileOptions
   • In this case, we do not want to apply the default compileOptions - setting compilerOptions to undefined could solve this
   • We can assume that extends can be an array of files, such as node18 and strictest (ignoring the ts-node bug)
3. Would like to use extends to set the base compileOptions, and also have a compileOptions where we specify specific overrides from that extended config
   • Again, we don't want the default project compileOptions to what's provided
   • Example use case: We want to have a tsconfig for a single file, and would like to "extends": "tsconfig.json" and include only that one file
     • From the docs:

       It’s worth noting that files, include, and exclude from the inheriting config file overwrite those from the base config file

[giseburt]

Forgot: We can use one of a couple of mechanisms for this. The one mentioned above is to set compilerOptions explicitly to undefined (or None in Python, as apparently that's how JSII translates None).

Another option is to add a side-option like applyDefaultCompilerOptions as a boolean that defaults to true form backward compatibility. Maybe a better name should be chosen, though. 😄

[mrgrain]

Can you explain if simply disabling the TS config and creating your own one would be a suitable solution in this scenario?

I'm asking because the issue describes a outcome, not a problem.

[giseburt]

@mrgrain You're right. This was sloppy and I apologize.

Disabling the TS config is non-ideal since too much machinery would need rewired, I believe.

However, as you said I described the solution but failed to describe the problem, and indeed the solution proposed doesn't solve the full range of problems. I've edited the description on this issue to correct the problem. Did I miss any use-case scenarios?

I think something like applyDefaultCompilerOptions as a boolean seems like a better solution for all scenarios.

[giseburt]

I guess an alternative would be if we could pass in a fully formed TypescriptConfig that is then used and wired in everywhere.

[mrgrain]

It does help a lot. Thanks for the clarifications. A real world scenario would also help.

Disabling the TS config is non-ideal since too much machinery would need rewired, I believe.

Sure. But is that not the same when you are completely removing compilerOptions?

From my perspective, the TypeScriptProject comes with certain assumptions about how a tsconfig looks like. I struggle to imagine a way to remove these assumptions while still providing a safe experience. So to me it feels more natural to say: "I want to opt out of these safe guards, I accept the risk and do this myself".

[giseburt]

There’s many more elements to a TSConfig that’s being managed by TypeScriptProject that I’d hate to give up, such as setting includes, excludes, outdir, etc.

The current defaults cover a somewhat narrow target type (node app, basically), which I’m not complaining about, but is somewhat brittle and puts the maintenance burden on this project. Each project subtype (such as a React one) provides overrides, which is great, and this should make that easier as well.

In my scenario I’m looking to (not in this issue or PR, just giving context) offer the use of the @tsconfig project settings, choosing a base and optionally extending other sets like strictest while still allowing overrides.

So, conversationally that would read as: “I’m building for Node20, would like the strictest settings, except exactOptionalPropertyTypes.”

Or, “I’m building for React in a browser, and bundling.”

That last one brings up the element of tsconfig.dev.json, which is for running projen, local utilities that use typescript (eslint, jest/ts-jest, etc), and may have wildly different settings than the target in tsconfig.json. When this is the case, the defaults work for the dev config (local tools) but not necessarily for the main config, building JavaScript for something else (browser, etc) to run.

[mrgrain]

In my scenario I’m looking to (not in this issue or PR, just giving context) offer the use of the @tsconfig project settings, choosing a base and optionally extending other sets like strictest while still allowing overrides.

That sounds great. Can you please start with an RFC issue for this wider feature before moving into smaller feature PRs. That will help us to understand the context of issue like this one much better.

[giseburt]

@mrgrain RFC here as requested: #3448