False positive in S4782

Rules and Languages Report False-positive / False-negative...
,
1

I’m also seeing this, using SonarQube for VSCode. The parameter type is Omit<MyComplexObjectType, 'specificAttribute'> & { specificAttribute?: undefined } which means “the same as MyComplexObjectType, but if the specificAttribute key is present in the object it is only allowed to be undefined.” Here, the question mark is not redundant. The rule “Optional property declarations should not use both ‘?’ and ‘undefined’ syntax (typescript:S4782)” states “This rule checks for optional property declarations that use both the ? syntax and unions with undefined.” That is a fine description and the rule would probably be OK if it were checking for unions which have undefined and something else. That latter requirement appears to be missing in practice.

2

Hi,

You’ve resurrected a topic that’s 4 years old. Per the FAQ, please don’t do that.

I’ve moved your post to a new thread. Can you provide your SonarQube for VS Code version and a reproducer?

 
Thx,
Ann

3

The earlier post was about the same issue; it just didn’t have enough detail. By discouraging building on existing reports that are still accurate, you effectively discourage duplicate-checking and are likely to wind up with more duplicate reports.

v5.2.3 reports the error in this code (demoS4782.ts):

type MyComplexObjectType = {
	specificAttribute?: string;
	otherAttribute: number;
	aThirdAttribute: boolean;
};

function demo(
	param:
		Omit<MyComplexObjectType, 'specificAttribute'> &
		{ specificAttribute?: undefined } //this line
	,
) {
	console.log('otherAttribute: ', param.otherAttribute);
};

The false-positive error report text says “Consider removing ‘undefined’ type or ‘?’ specifier, one of them is redundant.” If the question mark is dropped, the key MUST be present and have the value undefined. If the question mark is kept but the undefined is changed to anything else, that changes the meaning, allowing some other type of value.

5

Hi,

Thanks for the reproducer. I’ve flagged this for the language experts.

BTW, I moved you to a new thread because the people in the old thread stopped responding 4 years ago. They’re clearly done with the topic and likely don’t want to be bothered. :slight_smile:

 
Ann

6

I don’t share the same assumption about “clearly done.”

I have filed several bugs on open-source projects which went unaddressed for years before I stopped using that open-source software in part as a result of the impact of those bugs. In each case, the costs (incl. time) to understand the codebase thoroughly enough to investigate the cause, learn a new version-control system (if applicable), develop a fix, thoroughly test it, have enough knowledge of other codebase impacts to be reasonably confident the changes weren’t breaking anything else, review commit comment & PR format requirements, present a patch in exactly the right format, and answer sometimes-hostile questions from maintainers really exceeded both the available budget and the costs of switching to proprietary alternatives.

However, I do strongly prefer open-source and would like to move back, which would be a lot easier to do if I could see some signs of activity on those issues and maybe even solutions being developed, or if my own situation changed enough to be able to dive in; the motivation for the latter would be stronger with signals that others cared and were impacted too. So I haven’t silenced that bugmail or even filtered it out of the primary view, and it has a much higher average read rate than most of my email.

8

Hi @unblocker,

Thank you for the detailed report! This is indeed a false positive. The rule should not raise on an optional property whose type is exactly undefined.

We’ve created JS-1775 to track the fix. Thanks again for taking the time to spell this out so clearly. It helped us get the issue properly tracked.

François

10

Minor: tag the topic with JavaScript.