Instanceof requires callable or constructable right-hand side

• PR: Instanceof requires callable or constructable right-hand side #12728

• what about Symbol.hasInstance?
  • not now, maybe later
• The underlying code in static toString with incorrect type breaks instanceof #12709 is wrong. overriding the toString makes the class not an Object. will cause issues other than this.
• looks like a good change.

interfaces, spread and own/enumerable properties

• Object spread and enumerable properties #13148 (comment)

• works as designed
• users do not find this intuitive, and when they see the behavior perceive it as a bug
• conclusion:
  • only filter methods if we know they come from a class. otherwise keep them (i.e. object literals and interfaces).
  • may need to have annotations in the future to track enumrability on interface property declarations

Configurable errors in JS

• issue: Enable JavaScript specific warning behavior #6802

• allow types annotations in JS files

  • some sort of marker
  • the marker should say if you want errors
  • the marker should also say if type annotations are allowed
  • motivation, use tsc as a checker for your .js files, use other transpiler like babel to transform the code

• some rule proposal:

  • in a .js file
    • Always error on interfaces, types, namespaces, enums, or any TS-specific constructs
    • Marker to opt-in error reporting, types and type annotations
      • namespaces and enums should not be allowed here
    • Always use JSDoc
    • type annotations always win over JSDoc
    • Always show syntax errors

• what errors should here:

  • all?
  • ppl look for a linter mode
  • we need to configure these errors to make sure we error on permissiveness, e.g.
  • we do not want to make types configurable:
    • we need to define a taxonomy for errors
    • report errors the same way
    • commit to maintaining error codes consistent for ever
    • if we ever change anythign about error codes, or when they are raised, we break ppl's builds
    • C++ and C# struggled with allowing disabling specific errors

• is it a design goal to get to a 0 errors in a .js file without using type annotations?

  • obviously syntax and early errors should be allowed
  • we need to enable it first, then see what happened..
  • we can use comments on lines to disable errors on a specific lines/region
  • but most linters have that ability to disable specific errors

• we need to enable it for all files, or specific file by file to allow ppl to move from one file to another

• should strict-null-checks be on by default?

  • there is value here
  • users will have to write type annotations
  • what about users who want to write a pure JS?
    • .d.ts files are always allowed to provide additional type information

• checkJS as a new flag to allow errors in all .js files