In JS, type annotations should not block errors from the rest of the program

In a Javascript file that is checked by flow, we may see code like this (from create-react-app/packages/react-error-overlay/src/utils/parseCompileError.js)

export type ErrorLocation = {|
  fileName: string,
  lineNumber: number,
  colNumber?: number,
|}
function parseCompileError(message: string): ?ErrorLocation {
  const lines: Array<string> = message.split('\n');
  for (let i = 0; i < lines.length; i++) {
// ...................
  return fileName && lineNumber ? { fileName, lineNumber, colNumber } : null;
}

This behaves badly when the typescript compiler compiles it with checkJs on:

Expected behavior:

1. Errors on the type declaration and all the type annotations.
2. However, ErrorLocation should be declared as a type alias, and message, lines, etc should all have their declared types.
3. If they are used incorrectly, they should have errors.

Actual behavior:

1. Errors on the type declaration and all the type annotations.

In the language service:
2. message, lines, etc have the correct types, but ErrorLocation is type any.
3. If they are used incorrectly, they have errors.

In batch compilation:
2. No errors show up except those from (1), even if there are lots of other javascript files without type annotations.

Start with the checkJs example in create-react-app/packages/react-error-overlay/src/utils/parseCompileError.js and compare language-service behavior with batch compilation. Trace how type declarations and annotations affect ErrorLocation and the inferred types of message and lines. Done means annotation errors remain while unrelated JavaScript files continue to report their own type errors in both modes.