Proponents of Polish notation everywhere weep

I would mention let as the alternative for var, as currently this may be interpreted as var being the one alternative to const.

Also, where would var be absolutely necessary? (I can't think of any case.)

var is useful if you want to declare the value on the global scope:

// At root scope:
var foo = 1;
let bar = 2;
console.log(window.foo); // 1
console.log(window.bar); // undefined

I agree that this behavior is usually undesired in the first place and is very rarely actually useful. If this is ever needed there should be a sizeable comment next to it explaining exactly why it is necessary.

You don't want to look at the compiler tests, then :-)

An alternative alternative could be to have an enum to replace the boolean.

Could we add a caveat. I think the above is very true for public API, but for private(internal) API we often do boolean arguments for perf reasons and or size. We should make that distinction here as well.

Does this apply to Angular public API (i.e. stuff on our docs), public API of a class/module (i.e. public methods, exported functions, etc.) or any method/function?

👍
I would add another paragraph discussing for ... of vs "plain" for.

Is the Defaults to part needed when the default value is obvious in TS?

We need a rule that says it must be @returns and not @return. At all const 😛

Also, where would var be absolutely necessary? (I can't think of any case.)

const myCoolComponentFactoryResolvedComponentFactory = componentFactoryResolver.resolveComponentFactory(myCoolComponentFactoryResolvedComponent);

😛

FWIW, I don't like this rule 😢

Very surprised seeing this as well.
I was under impression that was a good practise.
I'm definitely fond of it.

💯

Not to start a bikeshedding war on code style, but the one advantage of throwing errors is that they can contain string messages about what went wrong which can be easily rethrown and composed to maintain useful error messages.

For example, consider the error-less implementation:

function computeAThing(): number|null {
  const firstResult = computeFirstPiece();
  if (!firstResult) return null;

  const secondResult = computeFirstPiece();
  if (!secondResult) return null;

  return firstResult + secondResult;
}

console.log(computeAThing()); // If this logs `null`, why?

There is no way to know which of the two pieces went wrong. Alternatively consider:

function computeAThing(): number {
  let firstResult: number;
  try {
    firstResult = computeFirstPiece();
  } catch (err) {
    throw new Error(`Failed to compute the first piece: ${err.message}`);
  }

  let secondResult: number;
  try {
    secondResult = computeSecondPiece();
  } catch (err) { 
    throw new Error(`Failed to compute the second piece: ${err.message}`);
  }

  return firstResult + secondResult;
}

try {
  console.log(computeAThing());
} catch (err) {
  console.log('Failed to compute a thing: ${err.message}');
}

The terrible try-catch syntax aside, this has the advantage of more accurately communicating exactly what went wrong at any given point in a computation with composable error messages giving full context about the operation. It also allows types to be much clearer; because computeAThing() always returns a number there is no ambiguity as to what null represents. Errors naturally propagate as well, so omitting a try-catch at one level of abstraction will still be caught at a higher level of abstraction.

I do agree that Error in JavaScript is not ideal. You can't wrap an Error like in other languages, you just have to throw a new Error with a concatenated message. try-catch syntax is awkward due to scoping and often requires a mutable let. It's also a bit of a pain to disambiguate different kinds of errors (though whether that is a good idea is a separate discussion).

My main point here is just that I don't feel we should outright ban them when we lack effective alternative options to fill that need. A contextual error message can be incredibly helpful for debugging problems.

A couple notable alternatives:

"Return an abstract data type (ADT)": As much as I like this pattern in general, I don't think it can be used in public-facing APIs because anyone using them in TypeScript can use an exhaustive switch statement, which means that adding a new failure state is actually a breaking change. Exhaustive switch is a useful feature, but most developers don't see this caveat and tend to misuse it as a result.

"Use a Result monad" (a la Result<T, Err> in Rust or Maybe is Haskell): Personally I think this an ideal solution but it just isn't well supported in the JavaScript ecosystem. We'd really need a standardized form of the type to be able to use it consistently and effectively.

var is useful if you want to declare the value on the global scope:

// At root scope:
var foo = 1;
let bar = 2;
console.log(window.foo); // 1
console.log(window.bar); // undefined

I agree that this behavior is usually undesired in the first place and is very rarely actually useful. If this is ever needed there should be a sizeable comment next to it explaining exactly why it is necessary.

This may not belong in style guide, but I'll put it here just in case:

One rule I always use is to prefer defer() over from() when translating a Promise into an Observable. Consider:

declare function doAsyncThing(): Promise<string>;

function doObservableThing(): Observable<string> {
  return from(doAsyncThing()); // doAsyncThing() is immediately invoked.
}

vs:

declare function doAsyncThing(): Promise<string>;

function doObservableThing(): Observable<string> {
  return defer(() => from(doAsyncThing())); // doAsyncThing() is invoked on `subscribe()`
}

You almost always want the latter option, so I'd love to see a little more awareness about this particular foot-gun. Though a style guide may not be the best place to put it.

Just as an idea/proposal: include human-language description of the test in case it has some non-trivial setup or scenario (in a trivial cases it's typically excessive). For example:

it('should calculate transitive scopes when overrides are present', () => {
  // Set up an NgModule hierarchy with two modules, A and B, each with their own component.
  // Module B additionally re-exports module A. Also declare two mock components which can be
  // used in tests to verify that overrides within this hierarchy are working correctly.
  TestBed.configureTestingModule({ ... });
  ...
});

This is actually @alxhub's idea that he mentioned during the code review for one of my PRs in
#36649 (comment).

Did you mean ### here?

To avoid Latin abbreviations (and confusion), we've been changing them to their English equivalents: e.g. --> for example