Versions used
SonarQube: Community Edition v8.8 (build 42792)
Scanner: 4.2.0.1873
SonarJS: 7.3.0.15071
Steps to Reproduce
- Setup multiple instances of the
typescript:S124template, all activated in the same Quality Profile. - Run a scan with the Quality Profile over a TypeScript code base which contain comments that trigger each of the instances of
typescript:S124. - e.g. if you have two instances of the template, one for
/foo/and one for/bar/, then run it over a codebase containing a.tsfile with// foo barin it.
Error Observed
- Only the oldest instance of
typescript:S124in the Quality Profile raises issues - any newer instances seem to be ignored.- e.g. in the steps above, if
/foo/was added first as an instance of the template, only issues for/foo/would be raised, and/bar/would be ignored.
- e.g. in the steps above, if
- My observations from trying to debug the issue:
- Problem appears to occur when setting up the
comment-regexrule ineslint. - If multiple instances of
typescript:S124exist, then multiple instances ofcomment-regexrules are passed to/init-linteron theeslint-bridgeserver. - When initialising the
eslintinstance using this array of rules,eslint-bridgeiterates over the provided rules and assign them to theruleConfigobject, using the rule key as the key of the object: https://github.com/SonarSource/SonarJS/blob/master/eslint-bridge/src/linter.ts#L150-L153 - I think the way this assignment is happening means only one
comment-regexrule can exist at a time in theruleConfigobject.
- Problem appears to occur when setting up the
Potential Workaround:
- Consolidate all instances of
typescript:S124in a given Quality Profile into one instance that matches each pattern - it is just regex after all, it can be merged. - I haven’t tested it, but I’m pretty certain that
javascript:S124would be plagued by the same issue, as would any template rule usingeslint-bridgein this way.
p.s. Technically this is a False Negative, but instructions did say that #bug:fp was for rules…