Default compiler options

[use-strict]

At the moment there are a bunch of opt-in compiler flags that are off by default. In most cases, they fix or add some behavior to the compilation that would have otherwise been a breaking change. This makes perfect sense for existing projects, but it shouldn't be default behavior for new ones.

IMHO, TS 2.0 would have been a good opportunity to turn some opt-in flags into opt-outs at least, if not removing them altogether. Avoiding breaking changes lead to a configuration nightmare where there are a dozen options doing similar things in slightly different manners. I hope you will take this into account for future releases.

For now my proposal would be to simply change the output of tsc --init. It won't affect users that create a tsconfig file from scratch, but it will at least give some useful defaults for the others, while keeping transparent what options were explicitly used.

Running tsc --init, yields this:

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "noImplicitAny": false,
        "sourceMap": false
    },
    "exclude": [
        "node_modules"
    ]
}

Proposal:

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "noImplicitAny": true,
        "noImplicitThis": true,
        "noImplicitReturns": true,
        "strictNullChecks": true
        "sourceMap": false
    },
    "exclude": [
        "node_modules"
    ]
}

My reasoning here is that new projects should have the stricter settings, because there is no legacy JavaScript code being migrated. The noImplicit* options make it easier to have good, type-safe code from the start, especially for new users, who don't understand the difference or see its advantages.

[jods4]

This is also the first thing I do when I start a TS project: create an empty tsconfig.json file and add a lot of compiler options. Even more than suggested above: noFallthroughCasesInSwitch suppressImplicitAnyIndexErrors skipDefaultLibCheck.

Undeniably, with 50+ compiler options, setting up a project can be confusing and tedious for both newcomers and old-timers alike. Back-compat has its price.

Here's another idea that may help: introducing profiles. It would be a set of default options that can be defined with a single key -- which is good for people upgrading or not using tsc --init. Of course, the profile can be overriden by specific options if you don't like a particular feature.

Something like:

{
  "compilerProfile": "2.0",
  "compilerOptions": {
    "module": "commonjs",
    "target": "es5",
    "sourceMap": false,
  }
}

What goes into a profile is debatable, but I would put all the language safety features by default.

[GauSim]

With profiles it would be more "black magic voodoo" behind the stettings. To solve this you would have to have to maintain extra documentation that states out with profile has with values set by default, to understand what is being used. This adds a lot complexity.

I think this is more about finding and setting good default values to start of a project, so there is a little more guidance what is a good direction to go and then make it easy to change the settings to the need of the project if needed.

I total love the idea of having a little but stricter defaults, because introducing them afterwards always is pain :)

[jods4]

@GauSim
I don't know, I imagine them really simple: "2.0" is TS with all safety features released up to 2.0 turned on, "2.1" is the default profile when TS 2.1 comes out if it contains new backward-incompatible checks.

I certainly don't suggest a whole lot of "2.0-es5-amd" voodoo variations. Rather: if TS 2.0 was TS first release, which features would be turned on? This is "2.0" profile, this is what you should use by default. The only reason you need to opt-in is because of backward compatibility.

So at most, we should add to documentation when a feature was introduced. For example:

Compiler option	Default	TS Profile
strictNullChecks	false	true since "2.0"

[RyanCavanaugh]

The design intent of tsc --init was to create a tsconfig.json file that runs the same as the commandline which created it, to provide an easy way to transition from commandline compilations to tsconfig-based compilations (since we're gradually introducing more and more things that are only available in tsconfig).

A good compromise might be to include the property keys for the things we think people should seriously consider turning on. In other words, create a config file that contains

    "noImplicitReturns": false,
    "noImplicitThis": false,
    // etc

Sort of a "menu" of options that should be appetizing 🍔 🍕. Remembering the exact names and spellings (and even existence) of these options is pretty hard so lowering the barrier to entry might help a lot.

[jods4]

@RyanCavanaugh A better tsc --init is a good thing.
I just wish we could cover more ground as this does not help people trying to upgrade an old project to the newer stuff, or people who don't use tsc. Personnally I start with a blank file in VS (Code or normal).

Spelling is not an issue for me thanks to the JSON schemas supported by both editors, but with the growing number of options it's getting more and more a memory exercise to find everything you want.

I also like my config files small but the pattern here is that they are getting more and more complex.

[mhegazy]

I also like my config files small but the pattern here is that they are getting more and more complex.

I do not think there is much we can do here. It is the nature of things i presume. as a language evolves, new features have to be under flags to ensure our existing users do not suffer in the transition. I understand the need to be more strict, and we do definitely recommend everybody to run with --noImplicitAny and --strictNullChecks, but i do not think we can force this on everyone just because we think it is the better way.

We have talked about an uper flag --strictChecks in the past that lumps all these, but it is not clear if this will make things easier or worse, as users start to opt out of some of the strict checks, but not others, and you have to know what is included by default and what is not. for instance should --noImplictReturns be lumped in what about --noUnusedParameters and --noUnusedLocales..

I will present this suggestion in the next desing meeting, and will see if there is enough support for it.

[Elephant-Vessel]

Yay for nudging users towards a stricter use of typescript. Not only for their own benefit, but for the self interest of the typescript community as it will improve the general code base out there and provide a more focused typed model, where both of which will also probably make a better impression within the general software development community. Which matters.

In the spirit of treating the properly typed typescript as the default, there is also the possibility to negate these compiler settings and give users the possibility to explicitly opt in for a weaker type system, instead of implicitly being opted in into what should be the default.

So instead of "noImplicitAny": false, we could have "implicitAny": true.

That would also reduce the ts.config bloat for default configs for stricter TS.

[use-strict]

@mhegazy , please also consider introducing breaking changes by changing the default value of the strictness options. While this sounds bad, existing users would only have problems when upgrading. Most should already keep a track of the roadmap and blog and have a good chance of learning about these changes and adjusting their config. After all, why/how would you be upgrading if you didn't know what was new in the first place?

On the other hand, new users, who just start learning the language, don't realize the difference and begin with bad habits, which not only hurts themselves but the community as well. I've lost count of the times I had to explain to beginners why any is bad and the number of PRs fixing creeping any-s in typings.

Towards this goal, it would also be beneficial for the documentation to better explain type-safety and its advantages (intellisense, find references, safe refactoring) and common mistakes (e.g. using any instead of generics, using optional properties instead of unions of well-shaped interfaces, index signatures, hardcoded strings instead of enums/constants etc).

[Elephant-Vessel]

@mhegazy

I understand the need to be more strict, and we do definitely recommend everybody to run with --noImplicitAny and --strictNullChecks, but i do not think we can force this on everyone just because we think it is the better way.

If having a default configuration is the same as forcing users into something, you will never get away from forcing the user one way or the other. If you don't want to "force" users to use a stricter configuration, your only alternative is to "force" them to use a laxer configuration.

You will never get away from the responsibility in providing a default configuration, so why not make is as good as possible?

If we play with our imagination and say that you update the default settings into a stricter mode continuously with each release as new settings mature, what negative consequences will come from this?

Worst case scenario, someone have to spend a couple of minutes of re-configuring the config if they haven't already specified the preference and really don't want the recommended settings.

On the positive side, new recommended features in regards of typing/strictness are clearly communicated and diversions from that requires an active choice from the user, which forces the user to at least be aware of what he/she is opting out from. People are very much nudgeable, and this will lead to a better knowledge and usage of the features of typescript, it will lead to generally better code in the wild and it will lead to more stable systems with less bugs in production.

Except from designing a great technical product with a lot of neat features, you also have the ability to influence and guide users, and to actively shape a knowledgeable and well informed community. The later is not insignificant.

[RyanCavanaugh]

Approved to put more explicit options in the tsconfig, initialized with their current defaults (pictured: not our design philosophy).

Proposed list, welcoming feedback. We can also discuss ordering (listing them here in what I'd consider to be "most likely to be toggled on").

noImplicitAny
strictNullChecks
noUnusedLocals
noUnusedParameters
noImplicitReturns
noImplicitThis
noFallthroughCasesInSwitch

[jods4]

@RyanCavanaugh I wish you would think about my suggestion above to introduce a "compatibility level" or "target version" or "profile" again. It is specifically not break all the things and has some advantages.
I did not come up with it, that's how .NET or SQL Server do it and it seems to work well enough for them, why not for you?

Your list is what I have in my current projects, with the addition of suppressImplicitAnyIndexErrors.

[RyanCavanaugh]

I don't think those are apt comparisons. For one, there's not a linear "progression" of the language as such -- it's not the case that we think 100% of people should be running with strictNullChecks on, whereas SQL (correctly) believes no one should be using RC4. Nor are we going to disable older settings, like SQL does. Similarly, it's not like C# changed the default settings for unsafe between 2.0 and 3.5, or that the default serialization mode of a BinaryFormatter changed between .NET releases.

[use-strict]

Maybe I would keep noUnused* out of the list, but I'm probably biased. I tried working with them and I didn't like the experience too much. IMHO, they fit better in the linter and not the compiler. My main problem is that they count as errors and not as warnings. There is no /* tslint:disable:rule */ -like override and sometimes there are legit cases to make exceptions. It's also annoying when you start writing new code and start in an error state (e.g. function parameters). You have to check all the time: "Did I actually make a mistake or is it just the unused param error?"

[jods4]

@RyanCavanaugh

it's not the case that we think 100% of people should be running with strictNullChecks on

Don't you think? In a few years time, when all definitions are updated to support null? What is the benefit not to? I have adopted it and ❤️. Several recent languages don't make it an option but a requirement (e.g. Swift, Rust).

I don't think those are apt comparisons. [...] it's not like C# changed the default settings for unsafe between 2.0 and 3.5, or that the default serialization mode of a BinaryFormatter changed between .NET releases.

Well, I don't know. I think it's a valid comparison.
They do some very disruptive changes. Like the CAS removal between 2.0 and 4.0, see compat flag NetFx40_LegacySecurityPolicy. Or when they changed the semantics of unhandled exceptions, see ThrowUnobservedTaskExceptions.

I think this would provide a better set of defaults for new projects, with backwards compatibility and the option to opt-out if so desired.
Today the situation is that you have a bad set of defaults and no clue how to opt-in or even what exists.
With your proposal, we would still have bad defaults, but easier discovery of opt-in flags.

@use-strict
Same here for noUnusedParameters. I don't use it because it catches few dead code and I sometimes like to have the full signature of functions, even if I don't use all parameters.
noUnusedLocal is great though, it found tons of dead code in our projects, especially unused imports after refactorings.

[Elephant-Vessel]

@RyanCavanaugh You know that Typescript is still considered more of an experimental/emerging technology in practice? Please use your grace period to make proper, valuable braking changes before the impact is many magnitudes greater. Just think of javascript, don't we all just wish that they had a cleanup somewhere when they had tried it out for a bit in the beginning before it was today and javascript is one of the most used languages and we hear from there and here that it will be the single most important language in the future?

I'm heavily invested in TypeScript as a developer and I'm the lead on a quite large TS-project where I'm working. I'd LOVE to see some breaking changes every now and then and spend some time adjusting to them. That tells me that you value a good product and I'm more than happy with contributing to making those kinds of changes possible. I feel that this is exactly what is expected of me as investing and embracing new technology, I don't assume I'm working on some legacy technology here.

(And in this specific case, I've are talking about darn configuration changes damnit. It's not even significant breakage.)

[kitsonk]

You know that Typescript is still considered more of an experimental/emerging technology in practice?

I beg to differ.

[Elephant-Vessel]

@kitsonk Show me the data then. Bloggers and twitters do not count, show me real world usage in professional environments.

[kitsonk]

Bloggers and twitters do not count, show me real world usage in professional environments.

• Visual Studio Code
• Angular 2
• Dojo 2
• RxJS
• Maquette

Plus I personally know at least a dozen private corporate enterprises using TypeScript in production. Some of them are listed here some of them are not.

Just because it is new to you doesn't mean it is new to everyone else.

[Elephant-Vessel]

@kitsonk Looks just like emergent tech to me, of course you know a handful enterprises that "use" typescript. We are talking about a language that has been existing for merely a couple of years and just is starting to get serious traction.

I did not ask for products or frameworks that use TS, I asked for actual real world professional adoption. Go to any random web development agency around the world. Do you seriously think TypeScript is at this point is time an established, adopted and mature technology, being a natural part of their toolbox?

It's production ready. It's hyped. It's good. I love it. But it is far from a globally adopted in regards of mass in professional environments. As in paid hours writing typescript. Compared to what I believe it will be in five or ten years, this is nothing.

[kitsonk]

You're point was TypeScript was "experimental" technology. You conflated emergent with experimental. Then you demanded real world usage in professional environments. I demonstrated some of that. Is there some level of usage that would make it un-experimental? You used this to justify making breaking changes. You seem to feel you have a better grasp of how and where TypeScript is being used than I do. While I won't get into it, I suspect my experiences outweigh yours. I am part of "any random web development agency around the world" who work with several enterprises where I know for a fact that TypeScript has been well established in those organisation and is a natural part of their toolbox.

You also seem to imply that you know better about TypeScript usage than the TypeScript core team. Good luck with that...

[Elephant-Vessel]

Experimental as from an organizational point of view. I don't know what you put in that term, but just like C# can be experimental for an organization that has not used it before. And I did not ask for examples of usage of examples of typescript in professional environments, I asked for data proving your refutation about my point about typescript today being generally experimental. As in an organizational point of view. As like that typescript is in the early adopters phase.

And yes, I used this to justify continuous making valuable breaking changes now before it actually will have significant negative consequences. So that we 1. Don't have to sit here in 15 years and all go God, why didn't they fix that when they could or 2. Have another Python 3 (which maybe was not so devastating after all).

I don't know what the core team thinks about the state of the adoption of typescript out in the wild among the common foot soldiers sitting in their cubicles writing code.

I personally know that one of the biggest nordic online gambling conglomerate is experimenting with typescript. I know that one a large Swedish governmental agency with hundreds of software teams experimented and actually decided to hold back on a general move towards typescript. I know that the 30+ people company that I currently work for would not have a single line of production code in typescript unless I had taken that initiative.

I know that there are a lot of talk about typescript, and that it is the new cool thing to try out if you are a "serious" developer, but I do not have personal experience from a single place where typescript is actually adopted organization-wide as a standard tool. But who knows, maybe we live in different worlds.

(And again, this specific case is just about simple configuration defaults. Dismissed as breaking change.)

[RyanCavanaugh]

Please let's not rehash a debate that is old enough to get a driver's license.

If we felt like making lots of breaking changes was the right thing to do, we would. By a long shot, it's the easier thing to do. And to be clear, we have made breaking changes when we felt the pain justified the value, including ones where we changed default settings.

We think we chose the default settings correctly when these flags were designed, and continue to believe they're the correct defaults. Sometimes things change (ES5 is now widespread, so we're making it the default compilation target), sometimes they don't (it remains the case that the vast majority of definition files are "ready" for strictNullChecks).

[Elephant-Vessel]

Ok, I think it's a perfectly reasonable situation that we have a different opinion on where the balance should be between doing no breaking changes and doing all breaking changes. I accept that, and in this regard I'm satisfied with at least making my opinion clear as a dedicated customer. Of course this kind of decision is best judged by you in the core team.

What I'm not very happy with, as a dedicated customer, is that the concerns and reasoning expressed in this particular case regarding the value and risk of this change is completely dismissed without any apparent counter-reasoning.

Maybe you have talked about this extensively in a design meeting, maybe there is design meeting notes I haven't read, but there is no such thing here in this thread. Instead we have an ironic meme about breaking all the stuff.

As a dedicated customer, I would be much happier if you guys gave your view on the value (or rather lack of value) of this change, the negative impact of this specific "breaking" change (that I believe to be insignificant) and why the overall balance is negative, instead of just (apparently) ignoring our arguments.

(And I don't understand the "it's not the case that we think 100% of people should be running with strictNullChecks on" in a previous comment above. Are we talking about completely removing compiler options or just changing the default values?)

[RyanCavanaugh]

completely dismissed without any apparent counter-reasoning.

"Don't make substantial breaking changes" is in our stated design goals. The burden of proof for going against the design goals lies with the side trying to violate them.

An unstated goal is that it should be reasonably easy to take an existing codebase written in JavaScript and get to a TypeScript codebase that compiles without error. A key thing we think about is someone who hasn't used TS before trying to convert their existing JS code. These people aren't going to unflip all the strictness flags because they don't know about those flags yet. They're going to compile one of their files and either get X warnings (in the unstrict case) or X * C warnings (in the strict case). Every time we increase C by making existing JS an error, we're narrowing the funnel for people adopting TS. And in truth C is already too high.

it's not the case that we think 100% of people should be running with strictNullChecks on

There's a spectrum here. We think anyone "serious" about TS is going to run with noImplicitAny on. But again, having that flag on by default massively increases the C factor above (because every existing JS function declaration parameter is going to be implicit any), and there are people who have large TS codebases written with that flag off who don't want to go annotate everything yet.

We also think most people want to run with noImplicitReturns on, but there are some people who really like "falling out" out of a function to return undefined, and that's OK. strictNullChecks implies a fairly large amount of work, both in terms of updating definition files and cognitive load for people who are used to something like C# or Java where null references are commonplace sentinels.

If I could just wave a wand and make everyone think like me, sure, all noX flags get turned on and no one ever has to migrate JS because the whole world writes TS all the time. But there's a big range of opinions out there and we don't think it's our position to be opinionated about what the "right" way to write typed JS is. Our stated mission is "optionally and gradually typed", not "big bang conversion and you must put all the types everywhere now". Maybe you want a little bit of sprinkling of types here and there, or maybe you want stricter settings. I like the latter, but a lot of people want the former, especially when they're just starting out.

We agree that we want the default configuration to be as good as possible. It's just a question of what "good" means. The logic is simply:

• tsc -init A B C should produce a tsconfig file that behaves identically to the commandline
• What should the default commandline be?
  • Whatever it is now (no breaking changes)
  • How did we come up with what it is now?
    • Don't shoot ourselves in the foot by making migration much harder than it should be

[jods4]

@RyanCavanaugh About migrating JS code, just sayin': with my proposal all it would take is remove "target": "2.0" from your tsconfig and you're back at the most lax TS compiler there ever was. That's not very complicated.

Or start without it and people who know better can just turn it on with a simple, predictable flag.

The current flag soup is no fun, and tends to become larger with each release.

[Elephant-Vessel]

@RyanCavanaugh Thank you, that makes much more sense. Wouldn't you say that this is actually less of an issue of a breaking change, and more of an issue regarding your unstated goal of making migration from javascript easier and less intimidating for beginners? The later seems like a valid goal, maybe it deserves to be explicit.

[aluanhaddad]

This makes me wonder why tsc --init currently includes

    "exclude": [
        "node_modules"
    ]

when excluding "exclude", no pun intended, results in better behavior for more users.

[mightyiam]

• 👍 "flag soup is no fun"
• 👍 easy migration from JavaScript

What is the middle path?

[jods4]

Just noticed that apparently MS committed to adding a new --strict option in upcoming 2.3, that by default enables most safety switches, and possibly future safety switches as well.
See #14486, I guess it will close this issue 🎉

It's not all-inclusive (apparently it does not contain noFallthroughCasesInSwitch or noImplicitReturns), which makes it a little awkward to know what's in there and what's not, but it contains all the important ones and it's a great step forward!

[mhegazy]

tsc --init should now default --strict to true. (see #14486)

[mhegazy]

@jods4, --noUnusedParameters, --noUnusedLocals, --noImplicitReturns and --noFallThroughCaseInSwitch are more of style checks and not type checks; and thus depend on user preferences in general, that is why these were not included.

--strict is intended to include additonal checks in the future.

[mightyiam]

Awesome step forward, it seems. Thank you.