Commits on May 7, 2023

1. 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`.
   
   Two open questions:
   
   1. Should I make `nodeType` non-nullable and update the places in the
      implementation that explicitly set it to `null` to omit it instead? A
      few places already omit it for e.g. parse errors or ignored file
      messages, so API consumers already have to check that it might not be
      set.
   2. `line` and column` are currently required but possibly `undefined`.
       - Ignored file messages currently omit `line` and `column`.
       - `Linter` explicitly sets them to `0` for two configuration errors
         (configured parser not found and no configuration found for file).
       - `Linter`'s `createLintingProblem()` has a `DEFAULT_ERROR_LOC` that
         defaults to line 1 column 0, but the default is only used for
         missing rule definition messages.
   
       Should I either:
       a. Keep `line` and `column` required but possibly `undefined` and
          update ignored file messages to explicitly set them to `0`,
          following precedent elsewhere?
       b. Or make `line` and `column` optional and remove fallback 0/0 or
          1/0 values from configuration issues?
   
       Option b is how I'd design the API from scratch because I wouldn't
       report a location unless we had a real locationl. But it might be a
       breaking change. Even though the type is specified as possibly
       `undefined`, in practice, some API consumers might only see messages
       that have real or fallback locations if they don't encounter ignored
       file messages. Option b would slightly increase the prevalence of
       location-less messages.

   

   btmills committed May 7, 2023
   Copy the full SHA

   760c458 View commit details

   Browse the repository at this point in the history

2. Add missing LintResult type import

   

   btmills committed May 7, 2023
   Copy the full SHA

   2be5776 View commit details

   Browse the repository at this point in the history

3. Use LintMessage type …

   All of these previously referenced a `Problem` type that does not have a
   definition.

   

   btmills committed May 7, 2023
   Copy the full SHA

   8338a95 View commit details

   Browse the repository at this point in the history

4. 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.

   

   btmills committed May 7, 2023
   Copy the full SHA

   8ae9800 View commit details

   Browse the repository at this point in the history

5. 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.

   

   btmills committed May 7, 2023
   Copy the full SHA

   f9cdf00 View commit details

   Browse the repository at this point in the history

6. 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 eslint#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`.

   

   btmills committed May 7, 2023
   Copy the full SHA

   bb09247 View commit details

   Browse the repository at this point in the history

7. Update LintMessage docs …

   This updates existing documented properties to match the updated `LintMessage`
   type and implementations.
   
   `messageId`, `nodeType`, and `suppressions` remain undocumented.

   

   btmills committed May 7, 2023
   Copy the full SHA

   55bed08 View commit details

   Browse the repository at this point in the history