Switches the error message emitted by the parser to the more specific _"An enum member name must be followed by a ',' or '='."_ when the expected comma doesn't follow the member.
`Number.MAX_SAFE_INTEGER` is `2 ** 53 - 1`, so anything greater than that is a 'dangerous' integer to store as a traditional number. This adds a codefix to suggest converting them to a `bigint` literal.
Fixes#5987.
Usages of a class property in a preceding property already gave an error, but the following doesn't yet:
```ts
class Test {
x: number = this.x;
}
```
As with other use-before-declare checking, IIFEs are not treated as invalid uses.
Starts on #29035 by creating a codefix to enable the `experimentalDecorators` setting in a user's config file, if one exists. The issue's discussion also mentions giving a more precise error message if the user has a jsconfig or tsconfig or creating one if not; I'd rather tackle those in separate PRs to keep this one small.
Doesn't create the code action if no config file is present. Otherwise keeps to the precedent of returning without action when the config file contents aren't the expected JSON structure (looking at `fixCannotFindModule.ts`). Moves a couple JSON helpers from that file into the sibling `helpers.ts` so both codefixes can use them.
Lengthening the reported error length to include all of the identifier necessitates scanning for all of the identifier. I also reset the `pos` after so other identifier scanning still happens.
Instead of modifying the logic in both `tsc.ts`to `watch.ts` by splitting `emitFilesAndReportErrors` in two, this adds an optional function parameter to report them.
Removes file counting for diagnostic messages, as they might not be coming from files.
Next commit will include tests.
Reports a "Found X error(s) across Y file(s)." message on each recompile if in both pretty and watch modes.
This commit intentionally doesn't include tests as I have a few questions about implementation details. Will ask in PR first.
I advocated against immediately clearing the console when starting --watch in #17756 because it was confusing to have the console suddenly become blank, wait a while, and _then_ give output. After using the feature for a little while, I think it's a little disorienting how the console will only start clearing after the first recompile. This change clears the console and immediately prints a new "Starting compilation in watch mode..." message.
Timestamps look like Gulp's, with grey times inside white brackets.
Files have cyan filenames, yellow line and column numbers, and grey TS{####} errors. I wonder if those are actually useful for folks using the --pretty CLI: are they used for anything outside Visual Studio... Can we just get rid of them?
Re-uses compiler/program's color logic in compiler/watch. The relevant variables are now exported and marked `@internal`. Is there a preferred way of re-using this code in both those files?
Josh Goldberg