Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sandersn opened this issue Apr 17, 2018 · 0 comments
Open
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Domain: JavaScript The issue relates to JavaScript specifically Suggestion An idea for TypeScript

Comments

@sandersn
Copy link
Member

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.

@mhegazy mhegazy added Suggestion An idea for TypeScript Salsa labels Apr 17, 2018
@weswigham weswigham added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Domain: JavaScript The issue relates to JavaScript specifically and removed Salsa labels Nov 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Domain: JavaScript The issue relates to JavaScript specifically Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

3 participants