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

Reorganize ESLint warning thresholds and output #5159

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

mcmire
Copy link
Contributor

@mcmire mcmire commented Jan 15, 2025

Explanation

Some lint rules are disabled because they generate many violations across the monorepo (mostly thanks to the recent ESLint upgrade). To be able to identify them and remove them, we have set these rules to generate warnings instead, and we have also implemented a quality gate to ensure that no new instances of these warnings occur in the codebase.

However, currently there are so many warnings and the output from ESLint is so large, that if changes are made in a branch that do end up producing new violations, it is basically impossible to know where those violations occurred. The format of the warning thresholds file, which is used to track changes to warnings, does not help things, either, because it only records the rules for which violations occurred and not the files that have those violations.

To address this, this commit reorganizes the warning thresholds file so that warning counts are filed first by file path and then by rule. A regression or improvement in lint violations is still determined by calculating a total and comparing it to the file, but then the script is able to show where new violations occurred. (As a plus, this commit also hides improvements if there are regressions.)

For instance, instead of saying something like:

🛑 New ESLint warnings have been introduced and need to be resolved for linting to pass:

- @typescript-eslint/consistent-type-exports: 19 -> 21 (+2)
- @typescript-eslint/no-base-to-string: 3 -> 1 (-2)
- @typescript-eslint/no-duplicate-enum-values: 2 -> 3 (+1)

it might now say:

🛑 New ESLint warnings have been introduced and need to be resolved for linting to pass:

- packages/controller-utils/src/types.ts
  - @typescript-eslint/no-duplicate-enum-values: 2 -> 3 (+1)
- packages/logging-controller/src/logTypes/index.ts
  - @typescript-eslint/consistent-type-exports: 0 -> 1 (+1)
- packages/message-manager/src/index.ts
  - @typescript-eslint/consistent-type-exports: 0 -> 1 (+1)
- packages/notification-services-controller/src/NotificationServicesController/index.ts
  - @typescript-eslint/consistent-type-exports: 0 -> 1 (+1)

References

Changelog

(N/A, developer-only change)

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've highlighted breaking changes using the "BREAKING" category above as appropriate
  • I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

@mcmire mcmire force-pushed the reorganize-warning-thresholds branch from 93d045c to b83c052 Compare January 15, 2025 23:08
Some lint rules are disabled because they generate many violations
across the monorepo (mostly thanks to the recent ESLint upgrade). To
be able to identify them and remove them, we have set these rules to
generate warnings instead, and we have also implemented a quality gate
to ensure that no new instances of these warnings occur in the codebase.

However, currently there are so many warnings and the output from ESLint
is so large, that if changes are made in a branch that do end up
producing new violations, it is basically impossible to know where those
violations occurred. The format of the warning thresholds file, which is
used to track changes to warnings, does not help things, either, because
it only records the rules for which violations occurred and not the
files that have those violations.

To address this, this commit reorganizes the warning thresholds file so
that warning counts are filed first by file path and then by rule. A
regression or improvement in lint violations is still determined by
calculating a total and comparing it to the file, but then the script is
able to show where new violations occurred. (As a plus, this commit also
hides improvements if there are regressions.)

For instance, instead of saying something like:

```
🛑 New ESLint warnings have been introduced and need to be resolved for linting to pass:

- @typescript-eslint/consistent-type-exports: 19 -> 21 (+2)
- typescript-eslint/no-base-to-string: 3 -> 1 (-2)
- typescript-eslint/no-duplicate-enum-values: 2 -> 3 (+1)
```

it might now say:

```
🛑 New ESLint warnings have been introduced and need to be resolved for linting to pass:

- packages/controller-utils/src/types.ts
  - typescript-eslint/no-duplicate-enum-values: 2 -> 3 (+1)
- packages/logging-controller/src/logTypes/index.ts
  - @typescript-eslint/consistent-type-exports: 0 -> 1 (+1)
- packages/message-manager/src/index.ts
  - @typescript-eslint/consistent-type-exports: 0 -> 1 (+1)
- packages/notification-services-controller/src/NotificationServicesController/index.ts
  - @typescript-eslint/consistent-type-exports: 0 -> 1 (+1)
```
@mcmire mcmire force-pushed the reorganize-warning-thresholds branch from b83c052 to 83b44c2 Compare January 15, 2025 23:10
@mcmire mcmire changed the title Reorganize ESLint warning thresholds Reorganize ESLint warning thresholds and output Jan 15, 2025
@mcmire mcmire marked this pull request as ready for review January 16, 2025 03:25
@mcmire mcmire requested a review from a team January 16, 2025 15:49
@mcmire mcmire enabled auto-merge (squash) January 17, 2025 18:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant