Skip to content
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

Add support to report errors in js files #14496

Merged
merged 29 commits into from
Mar 28, 2017
Merged

Add support to report errors in js files #14496

merged 29 commits into from
Mar 28, 2017

Conversation

mhegazy
Copy link
Contributor

@mhegazy mhegazy commented Mar 6, 2017

  • Adds --checkJsFiles --checkJs flag to enable error reporting in all .js files in a project (used in conjunction with --allowJs).
  • Adds a per-file version of the flag /// @check to enable the error reporting per file.

@Jessidhia
Copy link

Jessidhia commented Mar 7, 2017

This means that it'll be possible to opt-in to have types that can be inferred from the environment (lib, .ts, .d.ts or other parsed files) be checked, but everything else will be left as any, with closure compiler annotations (@type, @param, etc) for assertions?

Sounds pretty great for progressively migrating a codebase to typescript 🎉

I wonder how this interacts with noImplicitAny, though, since it's very hard to avoid in JS due to not being able to specify generic arguments, for example.

@mhegazy
Copy link
Contributor Author

mhegazy commented Mar 7, 2017

This means that it'll be possible to opt-in to check types that can be inferred from the environment (lib, .ts, .d.ts or other parsed files) will be checked, but everything else will be left as any, with closure compiler annotations (@type, @param, etc) for assertions?

correct. this is the intention.

I wonder how this interacts with noImplicitAny, though, since it's very hard to avoid in JS due to not being able to specify generic arguments, for example.

I do not know what is the best solution here. We were discussing this topic today, and we are doing some additional inferences/modifications to types in a .js file that we do not do in a .ts file. some of these involve anys. not sure what --noImplicitAny means in this context though..

@@ -0,0 +1,6 @@
// @allowJs: true
// @checkJsFiles: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might want to add @noEmit: true or @outFile to suppress all the Cannot write file... because it would overwrite errors in the baselines.

@@ -481,6 +481,12 @@ namespace ts {
name: "plugin",
type: "object"
}
},
{
name: "checkJsFiles",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we have allowJs, shouldn't this be checkJs? Having 'Files' on just one of them seems inconsistent.

// Instead, we'll report errors for using TypeScript-only constructs from within a
// JavaScript file when we get syntactic diagnostics for the file.
const checkDiagnostics = isSourceFileJavaScript(sourceFile) ? [] : typeChecker.getDiagnostics(sourceFile, cancellationToken);
// For JavaScript files, we don't want to report semantic errors unless ecplicitlly requested.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spelling

@@ -5878,13 +5879,24 @@ namespace ts {
amdDependencies.push(amdDependency);
}
}

const checkJsDirectiveRegEx = /^\/\/\/?\s*@check(\s+(true|false))?/gim;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe an @nocheck directive?

function shouldReportDiagnostic(diagnostic: Diagnostic) {
const { file, start } = diagnostic;
const lineStarts = getLineStarts(file);
let { line } = computeLineAndCharacterOfPosition(lineStarts, start);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • can line have more than one error where only one should be suppresed
  • seems that ts-suppress should be located immediately before the line to be suppressed so if user will put a comment between ts-suppress and target line it will stop working. Is it intended?

.map(d => allDiagnostcs[d].code);
}

function shouldCheckJsFile(sourceFile: SourceFile, compilerOptions: CompilerOptions) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the same snipped with this one. Can we share this?

@@ -5883,13 +5884,24 @@ namespace ts {
amdDependencies.push(amdDependency);
}
}

const checkJsDirectiveRegEx = /^\/\/\/?\s*(@ts-check|@ts-nocheck)\s*$/gim;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend you pull this out of the function and remove the g option. g is only really useful if you want to preserve lastIndex when using a regular expression in a loop. Also I would remove the m option as it should be unnecessary.

Consider this instead:

const checkJsDirectiveRegEx = /^\/\/\/?\s*@ts-(no)?check\s*$/i;
...
const checkJsDirectiveMatchResult = checkJsDirectiveRegEx.exec(comment);
if (checkJsDirectiveMatchResult) {
  checkJsDirective = {
    enabled: !!checkJsDirectiveMatchResult[1],
    end: range.end,
    pos: range.pos
  };
}

Capturing only the no allows you to avoid the additional case-insensitive string comparison.

@mhegazy mhegazy merged commit 0fd0903 into master Mar 28, 2017
@unional
Copy link
Contributor

unional commented Apr 22, 2017

Does this close #7661 ?

@mhegazy
Copy link
Contributor Author

mhegazy commented Apr 22, 2017

Nope.

@mhegazy mhegazy deleted the checkJSFiles branch April 22, 2017 19:36
@ifle
Copy link

ifle commented Apr 28, 2017

Very nice option. But it will be more powerful if allows to suppression several errors

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants