typescript:S124 - Cannot have multiple instances of "Track comments" template in the same Quality Profile

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:S124 template, 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 .ts file with // foo bar in it.

Error Observed

  • Only the oldest instance of typescript:S124 in 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.
  • My observations from trying to debug the issue:
    • Problem appears to occur when setting up the comment-regex rule in eslint.
    • If multiple instances of typescript:S124 exist, then multiple instances of comment-regex rules are passed to /init-linter on the eslint-bridge server.
    • When initialising the eslint instance using this array of rules, eslint-bridge iterates over the provided rules and assign them to the ruleConfig object, using the rule key as the key of the object: SonarJS/linter.ts at master · SonarSource/SonarJS · GitHub
    • I think the way this assignment is happening means only one comment-regex rule can exist at a time in the ruleConfig object.

Potential Workaround:

  • Consolidate all instances of typescript:S124 in 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:S124 would be plagued by the same issue, as would any template rule using eslint-bridge in this way.

p.s. Technically this is a False Negative, but instructions did say that #bug:fp was for rules…