-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: unify
LintMessage
type (#17076)
* Update LintMessage type to reflect implementation I made three changes to `LintMessage` and `SuppressedLintMessage` 1. Many places that create `LintMessage`s don't set `fatal`, so I made it optional. This would be a breaking change if we made types part of our exports, but in this case I believe it's updating JSDoc documentation to reflect reality. 2. Added an optional `messageId` property that's set by reports from rules. 3. Added an optional, nullable `nodeType` property. - Reports from rules set it to a value. - `applyDirectives()` explicitly sets it to `null` for unused disable directives. - `Linter`'s `createLintingProblem()` explicitly sets it to `null`. * Add missing LintResult type import * Use LintMessage type All of these previously referenced a `Problem` type that does not have a definition. * Replace ReportInfo type with LintMessage type `ReportInfo` was defined within `report-translator.js` to be very similar to `LintMessage`. It had one extra property, `source`, which wasn't ever set, so it would've been removed anyway. In `Linter.runRules()`, the return value from `reportTranslator()` gets pushed into a `lintingProblems` array and returned, and the return type annotation is `LintMessage[]`, which gives me confidence that `ReportInfo` was intended to be the same type as `LintMessage` elsewhere. * Make ruleId required but nullable Originally, we talked about the reverse - making `ruleId` optional but non-nullable and relying on `report-translator.js`'s `createProblem()` to normalize it. However, the `LintMessage` type would differ from `createProblem()`'s return value only by `null` vs `undefined` for `ruleId`. So instead, I made `ruleId` required but nullable and explicitly set it to `null` in the few remaining places that didn't already. * Add missing null nodeTypes `LintMessage.nodeType` is currently defined as required but nullable. Actual implementations explicitly set it to `null` in a couple places and omit it in several. After discussion in #16968, we initially leaned toward making it non-nullable but optional. I pursued that, but it resulted in slightly more runtime code changes, including some branching in `report-translator` to set it conditionally. Instead, I'm presenting the opposite solution of updating the remaining implementations to match the existing type definition by explicitly setting `nodeType` to `null`. * Update LintMessage docs This updates existing documented properties to match the updated `LintMessage` type and implementations. `messageId`, `nodeType`, and `suppressions` remain undocumented.
- Loading branch information
Showing
14 changed files
with
87 additions
and
55 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.