Files
Mofei Zhang 8c0829bda4 [compiler] Aggregate error reporting, separate eslint rules
All error messages that are not invariants, todos, or config validation errors are now moved to a registry.  This helps us check that error messages and linked documentation is uniform and up to date. This also lets us link error codes to linter reporting categories and break the single `react-compiler` rule up into many smaller rules.


Changes to error reporting in React Compiler:
- instead of writing raw error message, add a new ErrorCode to `CompilerErrorCodes`
- create errors by constructing a `CompilerErrorDetailOptions` with the correct error code, or calling `CompilerErrorDetail.fromCode()` / `CompilerDiagnostic.fromCode()`.

Changes to linter:
- `react-compiler` lint rule is now broken up into many smaller lint rules, each with their own test cases.
- linting no longer fails early when a non-fatal error is find. Instead, we now log and move on to lint for more errors!

Todos:
- Codebases previously using the eslint plugin may already have `react-compiler` eslint suppressions. Since this PR removes this rule, these codebases may get new eslint warnings on already-suppressed ranges. Some options I can think of:
  - Force everyone to add the new suppressions
  - Release a script to rewrite previous suppressions to the new suppressions. Codebases that had incomplete suppressions / waited to update may benefit here, as this still surfaces errors on previously-unseen suppressions
  - Hard code logic in our eslint plugin to avoid reporting if we see a `eslint-disable-next-line react-compiler`. This doesn't feel ideal
- Align on eslint plugin rule names and error code mappings
  - I aggregated a few error codes here. For example, reassigning and modifying local variables after render now have the same error code + message. See changes fixtures for more examples
- More test cases for linter rules. Will add these once lint rules are more finalized
2025-08-11 13:48:58 -07:00
..