ref: enable type-aware linting #88072
Conversation
eslint-pre-commit.config.mjs
Outdated
There was a problem hiding this comment.
this eslint config is used during pre-commit. It amends the regular config by turning off all rules that need type information.
eslint.config.mjs
Outdated
| // lint rules that need type information need to go here | ||
| export const typeAwareLintRules = { | ||
| name: 'plugin/typescript-eslint/typed-aware-linting', | ||
| rules: { | ||
| '@typescript-eslint/no-unnecessary-type-assertion': 'error', | ||
| }, | ||
| }; | ||
|
|
There was a problem hiding this comment.
I’m exporting the rules that need type information separately here so that we can easily loop over them in the eslint-pre-commit config.
no-unnecessary-type-assertion is just an example rule to turn on, we can add more here later, but we can’t really use any presets because we want to be able to explicitly turn them off.
There was a problem hiding this comment.
note: I found an even better way that doesn’t involve exporting the rules. We can just use:
extends: [typescript.configs.disableTypeChecked]
which is a built-in way to disable all rules that rely on the type checker
| - added|modified: '**/*.[tj]{s,sx}' | ||
| - added|modified: '**/*.{ts,tsx,js,jsx,mjs}' |
There was a problem hiding this comment.
I’ve included .mjs files here because they are also frontend related files, e.g. the eslint config files are in .mjs format.
|
🚨 Warning: This pull request contains Frontend and Backend changes! It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently. Have questions? Please ask in the |
…nting-poc # Conflicts: # tsconfig.json
Codecov ReportAll modified and coverable lines are covered by tests ✅ ✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #88072 +/- ##
==========================================
+ Coverage 87.71% 87.83% +0.11%
==========================================
Files 10064 10044 -20
Lines 569158 568454 -704
Branches 22352 22144 -208
==========================================
+ Hits 499264 499315 +51
+ Misses 69498 68723 -775
- Partials 396 416 +20 |
this avoids manually disabling rules, and we also don't need to export them anymore
This PR enables linting with type information; As this is quite slow, I have disabled those rules and the `projectService` for the pre-commit task. Linting with type information might generally not be compatible with file-by-file linting, as changing one thing can lead to lint errors in another file. To cover for that, I’ve created a new CI task `eslint` that will run eslint with the full set of rules on the whole repository. This means we now have: - linting in your IDE with the full set of rules - linting on pre-commit with a faster sub-set of rules (without type information) - linting in CI on the whole repo with the full set of rules (on every PR that has frontend changes) I’m expecting TypeScript to get significantly faster with v7 (typescript rewrite in go), at which point we could re-consider this split and potentially remove it.
This PR enables linting with type information; As this is quite slow, I have disabled those rules and the
projectServicefor the pre-commit task. Linting with type information might generally not be compatible with file-by-file linting, as changing one thing can lead to lint errors in another file.To cover for that, I’ve created a new CI task
eslintthat will run eslint with the full set of rules on the whole repository. This means we now have:I’m expecting TypeScript to get significantly faster with v7 (typescript rewrite in go), at which point we could re-consider this split and potentially remove it.