False positives for sonarjs/new-cap with Intl.DateTimeFormat()

Clean Code Report False-positive / False-negative...
1

With eslint-plugin-sonarjs, this expression triggers sonarjs/new-cap

Intl.DateTimeFormat().resolvedOptions().timeZone

Presumably it dislikes DateTimeFormat not being a constructor, but the name is beyond my control as it’s part of the EcmaScript standard Intl.DateTimeFormat - JavaScript | MDN

1 Like
2

Hi,

Welcome to the community and thanks for this report!

Just to be sure, are you using the latest version of the plugin?

 
Thx,
Ann

3

Issue is reproducible with eslint-plugin-sonarjs@2.0.4

1 Like
5

Hi,

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

 
Ann

1 Like
6

I was gonna report the same, almost didn’t see this was already reported. Would you mind adding the eslint tag ?

1 Like
8

Hello @geoffswift and @Avasam,

Sorry, can you please further explain what snippet is raising the issue?

If it’s only this

Intl.DateTimeFormat().resolvedOptions().timeZone

then I would not say is a false positive, as DateTimeFormat is a constructor, and the samples in the MDN linked page show that.

This Sonar rule modifies the behaviour of the ESLint rule new-cap, which also covers calling an uppercase function without new. I think our rule description should be completed to also explain that use case. I created a ticket to complete it.

Cheers

1 Like
10

I think I just didn’t realize Intl.DateTimeFormat is a constructor and the code that triggered sonarjs/no-cap on our side is indeed missing a new keyword as the rule would suggest.

2 Likes