Design Meeting Notes, 3/3/2017

[mhegazy]

TS strict Mode

• As we continue to make improvements to what we can check, we can break patterns that used to work
• So far to maintain back compat we have added new changes under flags
• it is getting confusing what flags to enable if you want "maximum safety"
• Changes seem to fall into two categories
  • "good breaks", all new errors flagged are good errors, i.e. bugs in user code, e.g. null/undefined checks in arithmetic operators
  • "opt-in"/"recommended" coding patterns, e.g. --strictThisChecks
• What should the philosophy be? more flags?
• Seems to be two general modes of operation
  1. I want to be fixed on a version, say TS 2.0, i want to upgrade to newer versions, and do not get new errors
  2. I want to be on the bleeding edge, always pick up new checks by default
• Add a new "uber" switch, to be "strict"
  • let's call it --strict
    • this would be our "recommended" mode
    • possibly the default in TS 3.0
    • tsc --init would include "strict": true
  • today this means --noImplicitAny, --noImplictThis, --strictNullChecks, --alwyasStrict
    • --strict => --noImplicitAny true, --noImplictThis true, --strictNullChecks true, --alwyasStrict true
    • users can "opt-out" of some of the --strict behaviours by turing them off, e.g.:
    • --strict --noImplicitAny false => --noImplictThis true, --strictNullChecks true, --alwyasStrict true
  • what about --noUnusedParameters, --noUnusedLocals, --noImplicitReturns and --noImplicitFallThrough?
    • should these be included by default?
    • should be warnings? instead
    • [mhegazy] I find them specifically annoying :)
  • In a future version --strict can get new checks enabled..
• should there be other "meta" flags
• should we have --loose flag?
  • what would a loose flag do?
  • JS-file behavior, aka Salsa
• So what are we doing for Salsa?
  • we want to start showing errors in .js files
  • errors should be Configurable:
    • enable/disable per file
    • enable/disable for project
    • skip error on next line
  • what about warnings vs. errors?
    • we have no warnings
    • we have no errors, the messages we show today are all warnings, output is generated any ways..
    • it is all about perspective
    • let's not derail this conversion with the details of the severity
• So what about JS specific behaviors:
  • here is the list of things we do for JS files and not TS files:
    • Recognize types in JSDoc
    • require calls in --m commonJs handled as import .. = require("mod")
    • Function signatures
      • Considering function parameters optional by default
      • Planned: treat functions using arguments as (...args: any[])=>T
    • Using new on functions with this.p = v assignments
    • Special property assignments treated as declarations
      • this.prop = value in functions and classes (roughly translates to property declarations)
      • FuncOrClass.prototype.prop = value, roughly translates to property declarations in a class
      • FuncOrClass.prop = value, roughly translates to property declarations in a class
      • module.exports.prop = value, roughly translates to export var prop = value
      • exports.prop = value, roughly translates to export var prop = value
      • module.exports = value, roughly translates to export = value
    • Emitting declaration files
    • No semantic errors in JS files
  • Should these be configurable too?
  • can you have the same behavior in a .ts file?
    • what does that mean?
    • may be you are in the middle of a migration, you already have JSDoc comments, why not read them..
    • would not this be too confusing for users.. too many options?
    • to be continued ..

[evmar]

I was thinking about this problem the other day, particularly the "upgrade" scenario (where you want to change the meaning "--strict" to become stricter over time without breaking apps). One solution that occurred to me is to make "tsc --init" be the one with the --strict flag, so a given version of tsc always specifies exactly the set of flags that mean "strict".

[mhegazy]

That was one option we discussed in this meeting. one thing is we want to avoid is making any promises that we can maintain a specific version behavior (include inferences, relationships, and errors) indefinitely.

The current plan with --strict (implemented by #14486) would include additional checks in the future; users can choose to opt-out of some of these checks directly e.g. --strict --noImplicitAny false.