Enable `--strict` by default

[DanielRosenwasser]

Background

Almost a decade ago, we began to add certain options beyond --noImplicitAny and --strictNullChecks. Flags like --strictFunctionTypes, --noImplicitThis, and --strictBindCallApply have been added to ensure most code is hardened against certain classes of type safety bugs. To avoid thinking about all the specific type-checking flags we recommended, we added the --strict flag as an easy way to enable them all. Each flag in the "--strict family" was still off by default, and so was --strict itself; but all of them would be conveniently enabled when turning on --strict. In cases where users found the behaviors of individual flags to be frustrating, or a new setting added under --strict broke their code, it has always been possible to toggle those individual settings to their false state even while --strict is set to true.

These settings were added as opt-ins so that our developers could avoid breaks, and migrations to TypeScript could be as easy as possible. But for years now, we've framed most of --strict as a collection of decisions we would have made in TypeScript if we had the chance to start things all over again. We still want to carry our community forward, but we want new TypeScript code to get the best experience out of the box.

While lots of code relies on laxer strictness settings, we have recommended that --strict be enabled for many years. tsc --init has set "strict": true for the better part of a decade. We are seeing that more and more developers pick TypeScript for JavaScript development, and expect stricter type-checking by default. For most new projects, --strict being off feels like it's usually an accident, and a pit-of-failure experience that we want users to avoid.

In TypeScript 6.0 and 7.0, we want to go a step further than explicitly setting --strict in tsc --init: by enabling it by default.

Proposal

TypeScript 6.0 will assume that --strict is on, unless explicitly disabled.
This means that specific settings like --strictNullChecks and --noImplicitAny will be enabled automatically unless --strict is explicitly turned off.

Projects that encounter breaks from this change will be able to do one of the following:

• adjust code to be compatible with all strict behaviors
• turn specific strictness flags off
• turn --strict off explicitly

Developers can consider partial migrations over time through a combination of the above.

Open Questions

What should tsc --init generate?

If TypeScript 5.9 and earlier still assume that --strict is false, should tsc --init should still continue explicitly setting "strict": true in generated tsconfig.json files? Is it worth keeping in there for awareness, or do we want to free users of ever thinking of --strict again?

While I personally felt that it would be worth keeping strict in there for broader compatibility with older TypeScript versions, I wonder how much of a win this really is. Over time, all developers will experience a new built-in TypeScript in their editors, or will be expected to use a the version of TypeScript that was run with tsc --init.

I don't think it hurts that much to leave things as-is for now, but I'm open to us changing it.

What should the default experience be in editors for loose files?

Today, editors like VS Code are able to specify the settings for loose files. By "loose files", we mean files where a tsconfig.json couldn't be found, or untitled TypeScript/JavaScript buffers. In these cases, we create what's called an "inferred project".

When a loose file is opened with our language service, we apply a default set of settings. For TypeScript, we try to adopt some loose runtime rules (e.g. high ECMAScript --targets, lax module resolution, etc.). This makes it slightly easier to have files can be built and run without a tsconfig.json or jsconfig.json.

While this is fairly rare for TypeScript files...

• it is definitely already common to see JavaScript files with no tsconfig.json or jsconfig.json, and
• it may become more common to run loose TypeScript "scripts" now that Node.js, Deno, and Bun all support running TypeScript directly.

For JavaScript, this matters more in cases where // @ts-check (or similar ways of checking JavaScript files in the editor) are used. Either way, noImplicitAny can be a bit rough when using untyped libraries. Maybe we should perform automatic type acquisition for loose TypeScript files, but it would be confusing to lose typing when a user creates their first tsconfig.json.

We could effectively punt on answering "what should the new behavior be?" by explicitly having editors turn --strict mode off for inferred projects. This would maintain the status quo today. We would either:

• modify editors using TSServer to explicitly opt in here
• set strict: false as the default setting of inferred projects

I do think we may want to experiment with --strict on by default in inferred projects before making a call here.

More Information

More information on 6.0 breaking changes and deprecations is available at #54500.

[DanielRosenwasser]

@remcohaszing had the following suggestion:

Wouldn’t it be better to reset strict mode instead? Strict is really a collection of options. All current strict options have proven useful and can be made default. Strict mode can be reused for future strict options.

I instinctively feel like "strict is on by default" is still more ideal, but I haven't given this other idea much thought yet.

[remcohaszing]

Yes, now in a bit more detail, as Bluesky posts are limited.

strict is not really an option. It’s more of a set of strict options that have proven to be useful, but haven’t been enabled by default. My idea is to decouple all (or most? Which ones is up for debate) current strict options from the strict option. This allows to use the strict option again for newer options that seem useful, but aren’t ready to be enabled by default yet.

So, the following options would be true by default:

• alwaysStrict
• strictNullChecks
• strictBindCallApply
• strictBuiltinIteratorReturn
• strictFunctionTypes
• strictPropertyInitialization
• noImplicitAny
• noImplicitThis
• useUnknownInCatchVariab

And "strict": true would be equivalent to for example:

{
  "compilerOptions": {
    "noPropertyAccessFromIndexSignature": true,
    "noUncheckedIndexedAccess": true,
    "verbatimModuleSyntax": true,
    // "someFutureStrictOption": true
  }
}

[ArnaudBarre]

@remcohaszing I think this would be bad for all the content available on the internet if the meaning of strict is changed.

Turning on strict is good but that's just one less flag to enable among tens to have good default on a React app.

On top of having strict enabled, I would be in favor a new modern or esm flag that would enabled a list of options like:

{
    "module": "ESNext",
    "allowImportingTsExtensions": true,
    "verbatimModuleSyntax": true,
    "moduleDetection": "force",
    "noEmit": true,
    "erasableSyntaxOnly": true,
    "noUncheckedSideEffectImports": true
}

Now that Node support TS, the only use-case for emit is restricted to some lib authors, which are the most knowledgeable TS config users, so I don't think it makes sense to emit by default.

[johnnyreilly]

I think this is a fabulous idea. My 2 cents:

If TypeScript 5.9 and earlier still assume that --strict is false, should tsc --init should still continue explicitly setting "strict": true in generated tsconfig.json files? Is it worth keeping in there for awareness, or do we want to free users of ever thinking of --strict again?

I think having "strict": true present in the generated config file is useful for awareness. If I'm coming new to TS and thinking "gosh this compiler won't stop shouting at me" seeing a "strict": true entry in the config file would prompt me to dig into what this might be used for and might ease the path to getting going.

set strict: false as the default setting of inferred projects

I also like this option for the Deno / Bun / Node.js running TypeScript reasons.

Wouldn’t it be better to reset strict mode instead?

@remcohaszing idea is interesting but I think would lead to confusion as the definition of strict would be changing depending upon the version of TypeScript. This feels like unnecessary cognitive load to force on the users

[mrazauskas]

should tsc --init should still continue explicitly setting "strict": true in generated tsconfig.json files?

Yes, please keep it (At least for TypeScript 6.). Some tools use the same tsconfig.json for multiple versions of TypeScript. For instance, TSTyche is able to test types agains several versions of TypeScript. The older TS versions simply load the same tsconfig.json. (Not sure how dtslint handles that.)

[remcohaszing]

The meaning of strict has changed several times in that sense. Strict mode was introduced in TypeScript 2.3. 5 of the 9 options included in strict mode are newer than that. That means at least 5 times strict mode has already changed. Let’s say we have have a new option. The option can go through the following phases:

1. The option does not exist.
2. The option exists, but is disabled by default.
3. The option is included in strict mode.
4. The option is enabled by default.

When a new option is introduced, it moved from phase 1 to 2. Some options turn out to be so good, they get promoted from 2 to 3.

Turning on strict mode by default, sort of merges phases 3 and 4. You can still disable strict mode, but then you disable a lot of useful options. My proposal is to instead keep strict mode as-is, in the sense that it’s disabled by default and the TypeScript team can add more future flags. My proposal is also to instead promote existing options to the 4th phase.

[tylersayshi]

If full strict by default is not possible... enabling strictNullChecks by default would be a big win in this line of thought.

[fabb]

Adding noUncheckedIndexedAccess to be active in strict mode would be a great dream, but probably too controversial 😢

Replacing all anys with unknown in standard lib return types would also be on my wish list for strict mode.