JS-1116 Fix S4335 FP on intersections with {} in generic type patterns#6339
Merged
ss-vibe-bot[bot] merged 4 commits intomasterfrom Feb 6, 2026
Conversation
Contributor
Ruling ReportCode no longer flagged (1 issue)S4335ant-design/components/date-picker/generatePicker/generateRangePicker.tsx:25 23 | generateConfig: GenerateConfig<DateType>,
24 | ): PickerComponentClass<RangePickerProps<DateType>> {
> 25 | type InternalRangePickerProps = RangePickerProps<DateType> & {};
26 |
27 | const RangePicker = forwardRef< |
Contributor
Author
|
github-actions[bot] 2026-02-06T15:02:54Z addressed |
Contributor
|
LGTM |
2b4a393 to
0f2f958
Compare
Contributor
Author
|
francois-mora-sonarsource 2026-02-06T15:24:42Z addressed |
0f2f958 to
2f6bca8
Compare
Tests cover the scenario where intersections with {} in generic type
manipulation patterns are incorrectly flagged as useless. Added valid
test cases for: Simplify/Prettify mapped type pattern, generic type
references with type arguments, interface property position with
generics, and reversed {} & GenericType order. Moved the
ExtendedProps<T> = SomeProps<T> & {} case from invalid to valid.
Relates to JS-1116
Add exception for intersections with {} when used with generic types.
Patterns like T & {}, GenericType<T> & {}, and { [K in keyof T]: T[K] } & {}
are legitimate TypeScript idioms for type normalization and non-nullability
constraints. The new isGenericTypePattern check exempts mapped types, generic
type references with type arguments, and type parameter references.
Implementation follows the approved proposal algorithm with an improvement:
Pattern 3 uses the TypeScript type checker (isTypeParameter) instead of a
name-based heuristic for more accurate type parameter detection.
Relates to JS-1116
Ruling analysis confirmed the implementation is correct: the single
ruling entry (ant-design generateRangePicker.tsx) correctly no longer
raises an issue for `RangePickerProps<DateType> & {}`, which is a
legitimate generic type reference pattern.
Added a test case for generic type references with `& {}` inside a
function body, where the type parameter comes from the enclosing
function rather than the type alias itself.
Ticket: JS-1116 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2f6bca8 to
8181912
Compare
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.




Summary
Fix false positives in rule S4335 where intersections with
{}in generic type manipulation patterns were incorrectly flagged as useless. Patterns likeT & {},GenericType<T> & {}, and{ [K in keyof T]: T[K] } & {}are legitimate TypeScript idioms for type normalization and non-nullability constraints.Changes
isGenericTypePatterncheck that exempts mapped types, generic type references with type arguments, and type parameter references from being flagged when intersected with{}isTypeParameter) instead of name-based heuristics for more accurate type parameter detection{} & GenericTypeorderExtendedProps<T> = SomeProps<T> & {}from invalid to valid test casesgenerateRangePicker.tsxno longer raises an issue forRangePickerProps<DateType> & {})Relates to JS-1116