chore(eslint): add @typescript-eslint/no-unsafe-type-assertion rule#1534
Conversation
…ule and update ignore patterns
🦋 Changeset detectedLatest commit: 2e14eb2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR Review✅ No critical issues found. This PR successfully enables the Positive aspects:
Minor suggestions (non-blocking):
Overall: Clean refactor that enhances type safety without introducing bugs. Good incremental improvement to code quality. |
E2E Test Results✅ All tests passed • 52 passed • 5 skipped • 703s
Tests ran across 4 shards in parallel. |
| '@typescript-eslint/no-empty-object-type': 'warn', | ||
| '@typescript-eslint/no-explicit-any': 'off', | ||
| '@typescript-eslint/no-floating-promises': 'error', | ||
| '@typescript-eslint/no-unsafe-type-assertion': 'error', |
There was a problem hiding this comment.
Type assertion will error in common-utils pkg going forward
e33b751 to
54f5752
Compare
@typescript-eslint/no-unsafe-type-assertion rule@typescript-eslint/no-unsafe-type-assertion rule
Instead of using type assertions to narrow a type, it's better to rely on type guards, which help avoid potential runtime errors caused by unsafe type assertions.
Currently the rule is enforced in
common-utilspkgDup of #679