Have js-sdk pass TSconfig `strict: true`

[ShadowJonathan]

This will remove tons of bugs simply by virtue of function types becoming more correct.

Sub-issues;

• strictNullChecks: Have js-sdk pass strictNullChecks: true #2112
• strictFunctionTypes: TBD
  • Switch away from using method-defined interfaces for base-class definition #2114
    (to properly check interface implementations)
• noImplicitAny: TBD
• ... (more from https://www.typescriptlang.org/tsconfig#strict)

Related: #2115

[turt2live]

What are the benefits to doing this? I've yet to be convinced that strict: true is a good idea :/

[ShadowJonathan]

strict: true will enable 8 other linters by default, this issue is meant to be partially a tracker for these as well.

All of these linters make TypeScript apply more scrutiny and static analysis to the TS source files, which in turn would make the overall program more deterministic and type-safe.

These are the applied linters, i'll explain each in turn;

• alwaysStrict
• strictNullChecks
• strictBindCallApply
• strictFunctionTypes
• strictPropertyInitialization
• noImplicitAny
• noImplicitThis
• useUnknownInCatchVariables

---

alwaysStrict

This'll make Typescript emit its javascript in strict mode, and type-check it the same way as it would be in strict mode.

This has a number of advantages, all of which are listed here, but a few highlights;

• Unique function parameters
• Throw on assignment to get/readonly property
• Throw on assignment to a nonasignable global (undefined, Infinity, etc.)

Ultimately, the lint description highlights it as thus;

ECMAScript strict mode was introduced in ES5 and provides behavior tweaks to the runtime of the JavaScript engine to improve performance, and makes a set of errors throw instead of silently ignoring them.

strictNullChecks

This is explained in #2112 (comment).

strictBindCallApply

Will apply stricter checking to .call, .apply, and .bind, making sure that the types given to its arguments are the same as given on the function signature.

If this is not enabled, these calls will not type-check, and also not inherit return types from the function, instead returning any.

strictFunctionTypes

This will more strictly interpret function types, making sure that functions are unassignable if the defined function type cannot be completely "covered" by the function-to-be-assigned, example;

function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
type StringOrNumberFunc = (ns: string | number) => void;
 
// Unsafe assignment
let func: StringOrNumberFunc = fn;
// Unsafe call - will crash
func(10);

With this checker on, the above will raise a type error during linting, without it, it will be silently ignored.

#2114 is a derivative of this, making sure that every interface will have its functions applied more correctly.

strictPropertyInitialization

This will make sure that any and all properties on a class are initialized on construction.

Example, below, every property is "accounted for" during construction, except email, which will erroneously become undefined after construction.

class UserAccount {
  name: string;
  accountType = "user";
 
  email: string;
  address: string | undefined;
 
  constructor(name: string) {
    this.name = name;
    // Note that this.email is not set
  }
}

noImplicitAny

This will, in essence, make sure that every function parameter is property type-annotated.

This'd disallow the following, and raise an error when encountering it;

function doThis(thing) {
  // what type is thing???
  thing.doSomething() // not type-checked, as `thing` is `any`
}

noImplicitThis

This one is more subtle, but best explained with the following example;

class Rectangle {
  width: number;
  height: number;
 
  constructor(width: number, height: number) {
    this.width = width;
    this.height = height;
  }
 
  getAreaFunction() {
    return function () {
      return this.width * this.height;
      // error: 'this' implicitly has type 'any' because it does not have a type annotation. 
    };
  }
}

This makes sure that every this invocation is - at the very least - definitively typed.

useUnknownInCatchVariables

This will, in essense, treat the e from every catch(e) as unknown.

unknown and any share similar traits, but a basic one is that, while any is assignable to any type, unknown is assignable to none, bar itself. This means that let err: Error = e; will not work, an explicit cast like as Error is needed to override the invariant.

There is a good reason that this must be the case in catch, as any function down the call stack can throw any sort of value up the chain, so when this arrives, typescript cannot check anything, it is up to the programmer to start applying type guards ("let me check this first") or type assertions ("i know what i'm doing, treat this variable as this other type").

try {
  // ...
} catch (err) {
  // We have to verify err is an
  // error before using it as one.
  if (err instanceof Error) {
    console.log(err.message);
  }
}

err here would remain unknown until TS notices us adding a type guard, after which it'll treat err as Error.

---

This issue was made with the idea that all of these checks should've been implemented into js-sdk "yesterday", that these checks are needed to keep a large codebase in check, and make sure all of its behavior is (more) deterministic.

The alternative would be that this behaviour would be unchecked, such behaviour would then break the basics of TS' type safety, creating a false sense of security, and leading to headaches, programmer bugs, runtime nullability problems (propagated undefined and thrown errors on calling undefined as a function), and at worst, vulnerabilities.