Design Meeting Notes, 5/10/2017

[mhegazy]

CheckJs feedback

Inference failures and explicit type parameters

• also contextual type and jsdoc..
• Type checking Javascript object literals is not open-ended in Maps #15618
  • @type should take precedence, should propagate contextual type
  • cast syntax, add /** @type {number} */ syntax.
  • no type args needed for now

Use of JSDoc types:

• in member assignment: Type annotations are frequently ignored in --checkJs #15707
  • respect @type always
• function signatures: Incorrect Error Message reported in JS file #15663
  • function implementation is the source of truth, consult jsdoc for types
• contextual type: Type checking Javascript object literals is not open-ended in Maps #15618
  • flow contextual type from @type tags

Globals

• [Discussion] Better Way to Declare Globals in JavaScript files #15626
  • support @var here
  • adding globals to window is tracked under Add support for ES global proposal #12902

JSDoc value references to types

• JSDoc Does not Pick up Type imported using Require #14056
• [Salsa] Provide a JSDoc equivalent of import { ..} from "mod" #14377
  • look up types in jsdoc for values

Errors as warnings

• Add support for diagnostic severities #13408
• Ability to group errors together #15550
  • should we disable specific errors?
    • no, disable TS2339 (type {0} does not have property {1}) and TS2322: (Type {0} is not assignable to type {1}) and you have almost eliminated the whole value prop for TS
    • So turn them all into warnings
      - but all our errors are warnings, they do not block emit
    • just make them all warnings level-wise
      - ppl seem to like warnings more than errors, no immediate action is implied
      - @alexeagle noted that from his Java research ppl always ignore warnings, why have warnings if users do not care about them, and i they care, why do not they break the build?
    • not all errors created equal, syntax errors are different from noUnusedLocals
      - but you can disable --noUnusedLocals all together.. so why enable it to ignore its output
  • No conclusion here, same discussion like the last 10 times we talked about this, same conclusion:)

Completions

• JavaScript suggestions are currently too intrusive  vscode#26340 and Filter unnecessary type suggestions in completion list #15750
  • filter types from completion list in TS
  • why have not we done this before?
    • cause we have not done it :)
• Extra entries for JavaScript auto complete(intellisense) make no sense #15679
  • Seems reasonable, only show completions that will not produce errors if we know the type of the entity

Spread and call

• Issue: Proposal: Support spread operator for arrays and tuples in function calls #5296
• Report for JS files: Error TS2346 when importing React components written in JavaScript  #15375
  • allow this for TS and JS
  • treat the spread as an infinite list of optional arguments, allow them if is assignable to target parameter list, ignore extra arguments
  • no implications for tuples at the time being

--d with --allowjs

• Allow --declaration with --allowJs #7546
• Allow declarations:true to work with checkJs #15718
  • do it!