Make `--strict` the default in TypeScript 3.0

[aboyton]

Search Terms

strict default

Suggestion

Congrats on getting towards a 3.0 release. I'm always in constant amazement by the work you are all doing, both in features released and discussions on Github so thank you for that.

Now that you are planning on releasing 3.0 I was wondering if it would be a good idea to make --strict default.

While anyone has the option of turning --strict on or off as they please, I think defaults matter, especially for newcomers. Sadly I fear many are missing out on the advantages that --strict brings as they don't realise that they can turn it on. Even the handbook generally assumes that it is turned off.

As a note: we encourage the use of --strictNullChecks when possible, but for the purposes of this handbook, we will assume it is turned off.

Given that you're planning a major version release I was wondering if now is a good time to consider making --strict default to true. Obviously anyone could change the setting back off if they don't want it turned on.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

[MartinJohns]

strict is at least already the default for new tsconfig.json files.

edit: I just realized you mean a default value of true when the flag is absent.

[RyanCavanaugh]

As noted, it is the default under tsc --init.

One of the reasons we don't adhere to semver is that we don't make giant boil-the-ocean breaking changes between any two versions - our policy is that you should feel safe upgrading from one TS version to the next and only get a handful of new warnings that should be mostly useful. There's a 0% chance turning on strict in an existing codebase won't generate a huge number of warnings. And this is all to say nothing of the fact that a large proportion of DefinitelyTyped definitions aren't yet updated for strictNullChecks compliance, so any given codebase's ability to turn on all of strict is kind of in the air.

If people want strict on, it's usually trivial to do so, and we encourage them to do so with tsc --init. If they want their build to keep working on upgrade, we'd really like to help them with that. Throwing up a giant wall of errors (which won't have any clear explanation as to why they're suddenly appearing!) on the next TypeScript upgrade is not going to change anyone's mind about the relative usefulness of strict in a positive way.

[aboyton]

I hadn't realised that tsc --init turns --strict on. That is definitely nice.

I think for me it's more a question of "If I read some TypeScript code online, can I assume --strict is turned on?". When I read TypeScript's documentation or some random blog post the answer is generally "no" which I think is a shame.

It's an interesting point about DefinitelyTyped not necessarily supporting --strict although to be honest I'm not sure if that means we should make it default so people start writing type definitions with --strict in mind or if we should leave it off. It seems a bit of a chicken and egg problem and the longer we leave it the worse it would become. I personally definitely use DefinitelyTyped definitions with --strict on and have just assumed that this is fine. Maybe I shouldn't be?

I wasn't meaning to suggest anyone upgrading to 3.0 would need to fix all type errors that --strict emits. I was simply assuming that anyone upgrading would turn --strict off if they don't want it on for whatever reason just like when upgrading to 2.7 I had to turn --strictPropertyInitialization off (as I'm using Angular).

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.