Problem understanding installation guide

[hubertgrzeskowiak]

The guide tells to "Make sure you have a tslint.json file next to sonar-project.properties, or specify its path using the sonar.ts.tslintconfigpath setting". Where do I find or get that file from? I'm not into TSLint and only installing it for a collegue.

Also the guide doesn't point out whether the config is searched on the build server or on the sonar server. We're only using remote scanners which are reporting to the central server.

[Pablissimo]

The config needs to be visible to the scanner, so it can be on a shared drive if desired but typically would be part of the code under analysis. You can generate a default one using the tslint -i command, but you'd then need to configure the rules you're actually interested in checking by altering that configuration file.

See https://palantir.github.io/tslint/rules/ for info on the rules available in tslint, and how to configure them.

[hubertgrzeskowiak]

Thanks. So basically I run tslint -i and put the file somewhere in the project. The sonar.ts.tslintconfigpath property then needs to point to that file, right? Are the Sonar-set rules ignored when using that file?

[Pablissimo]

It's the intersection of the two sets of rules.

• You configure, via tslint.json which rules you want tslint to check and report on
• You enable or disable, via SonarQube, the set of all possible tslint violations that you actually care about
• The set of violations that SonarQube reports are those that tslint reported (based on your tslint.json) and that you've enabled in SonarQube

Typically I would recommend getting your tslint.json setup so that it doesn't return anything you're not interested in, then setup SonarQube to just enable all of the TypeScript rules irrespective of if you care about them - that way, what you see on a manual run via the console will match SonarQube, and you then only ever have to change things in one place if you want to start paying attention to a new tslint rule violation.

Make sense? If so I'll document it!

[pyrocks]

Hi,

I have a related question - I'm not sure I understood how to "map" rules to sonarqube. You gave a configuration example using the export-name rule from the tslint-microsoft-contrib package - but it's not clear where this configuration needs to be (i.e what file, where do I configure the scan to read this file - is it related to sonar.ts.ruleconfigs? if not what is the role of sonar.ts.ruleconfigs and how to use it?)

Basically I added the export-name rule to my tslint.json:

{
    "rulesDirectory": [
        "node_modules/tslint-microsoft-contrib"
    ],
    "rules": {
        "export-name": true,
...

When I run a scan - it appears in sonar as "Code Smells" - but debt remains "A" and when clicking on one of the items found I see a message saying "tslint issues that are not yet known to the plugin". I also cannot see this rule in the "Language=TypeScript" rules in sonar.

If you could clarify that bit - it would be excellent.

Another small question: I do see rules such as "Branches should have sufficient coverage by unit tests" (disabled by default) - but since this plugin has no support for loading unit tests - what is the use of this?

Thanks!

[Pablissimo]

So this isn't particularly well documented, but the theory is that you can set a blob of text via the admin interface into the sonar.ts.ruleconfigs setting that has a similar format to this in-built set of rules described by this properties file.

Once you set up the sonar.ts.ruleconfigs property, you need to restart the SonarQube server (you can do that via the admin interface too) and then re-run analysis.

Screenshot below's from a 5.6 install as an example. If you haven't set up a set of properties like the below for any custom rules, any violations go into the 'tslint issues that are not yet known to the plugin' bucket. Not seeing the rule in the Language=TypeScript filter suggests a defect, will have a look.

To your second question - the plugin supports parsing unit test coverage, just not the result of unit test runs (nor counting the number of tests available in a project). So rules like branch coverage would, in theory, work if you had an LCOV file that gave branch coverage information for the project under test. I've not tested branch coverage though, so that might be wishful thinking!

[pyrocks]

Thanks for the detailed answer and link to the file - it is very helpful. Will try it out tomorrow. If you can add a similar explanation to the documentation I'm sure it would help others as well. Cheers.

[Pablissimo]

Really I need to setup the wiki with some finer-grained documentation than the readme can really provide. Shall make sure I add a worked example though!

[pyrocks]

Using Sonar 6.1 - I tried to configure the export-name in TypeScript configuration similar to the screenshot you attached, restarted Sonar (also with systemctl), re-ran the scan - doesn't work. The issues are still "tslint issues that are not yet known to the plugin" and do not appear in Language=TypeScript filter.

[Pablissimo]

Hmm, unsure what's happened there then - will have to reproduce locally. Just for fun can you try:

• Running the scanner with the -X -e flags, and finding the exact command line used to execute tslint
• Remove the -out 'whatever the path is' parameter from the command line but otherwise run it in a console and confirm that the rule name it spits out for your breaches matches what you've got in the admin API

Entirely possible that I've regressed the extra-rules functionality, while there are unit tests for it there're no integration tests (yet) round the plugin.

[pyrocks]

-e is deprecated :)

Here is the command (replaced actual path with /project_workspace): 09:22:35.030 DEBUG: Executing TsLint with command: node /project_workspace/node_modules/tslint/bin/tslint --format json --rules-dir /project_workspace/node_modules/tslint-microsoft-contrib --config /project_workspace/tslint.json <list of ts/tsx files to be scanned and I omitted>

There is no -out parameter, but I ran it manually - and got the correct rule name (replaced actual file name with file1):

[prompt#] node /project_workspace/node_modules/tslint/bin/tslint --format json --rules-dir /project_workspace/node_modules/tslint-microsoft-contrib --config /project_workspace/tslint.json file1
[{"endPosition":{"character":70,"line":645,"position":35945},"failure":"The exported module or identifier name must match the file name. Found: file1 and connect(mapStateToProps, mapDispatchToProps)(ThemeDemo)","name":"file1","ruleName":"export-name","startPosition":{"character":15,"line":645,"position":35890}}]

[Pablissimo]

Cool, that's perfect thanks - last question, what version of the plugin are you running?

[pyrocks]

0.94

[Pablissimo]

Did you activate the newly defined rule in your TsLint rules profile? This is a step I hadn't appreciated worked how it does (I had thought it activated by default, which would make way more sense), but if you dive into the admin panel, hit up Quality Profiles, then TsLint and see if any rules are listed as Inactive. That step fixed my local repro, and I now have it cheerily reporting.

If that works, will add a new issue to try to auto-activate those rule types (or at least maybe warn in the logs when custom rules are setup but not enabled in the quality profile).

Edit: On reading the readme, clear I've at some point added a note that you have to activate the rule which I'd forgotten myself, so obviously that's working well...

[pyrocks]

Confirmed - after activating the rule in the Quality Profiles section it appears correctly with the debt and description. I would suggest to just add to the documentation where to add the custom rule configuration (Administration-> TypeScritpt -> TsLint Rule-Collections). You could also point to your properties file for the built in rules (the one you linked above) as a good configuration example). Cheers!