Paul O'Neill

So the thing that's blowing up is the call into the SonarQube API to request all settings that start with a given key, which doesn't seem to handle the case...

Current thinking goes along two lines: 1) Implement a minimal TypeScript parser to track executable lines in the TypeScript sense 2) Implement a custom tool in TypeScript using the TypeScript...

There isn't yet - the closest is the non-comment lines-of-code metric. Could be added as a feature though, since it's just the inverse of that logic I guess...

I'm just struggling for time @TristanFAURE - aiming to find a couple hours this weekend

Yep, but the only mechanism that lets it work in `tslint` is to specify a single project file to analyse, rather than individual .ts files. Seems that's not been documented...

You've set a project path in your sonar-project.properties, it seems from the log? i.e. you'll have a key somewhere `sonar.ts.tslint.projectPath=src` If you're specifying projectPath, you need to specify the full...

Sorry, been away for a while - your log suggests that `tslint`'s returning relative paths that the plugin can't then translate into files in your analysis set (line 261 onwards...

Won't happen on its own at the minute I don't think (though given that I lifted the parser code at least from the SonarJS plugin I'm not sure how I...

I don't know about that actually, to be honest I'd maybe start with just splitting by comma so that the behaviour matches the SonarJS one and then we can see...

It's not something that's currently imported via the plugin, and getting it in there may be quite specific to the runner being used to execute the tests (and what reporting...