[NEW RELEASE] (SonarTsPlugin) TypeScript 1.1.0

[Paul O'Neill]

Hi all,

I maintain the SonarTsPlugin project that brings TypeScript analysis (via tslint integration) and code-coverage information to SonarQube. Version 1.1.0 was recently released fixing a few minor issues listed on the release note page linked below.

The plugin:

• Runs tslint or reuses output from an existing pass to create SonarQube issues
• Parses LCOV code coverage data
• Performs basic NCLOC counting

Project site: https://github.com/Pablissimo/SonarTsPlugin

Issue tracking: https://github.com/Pablissimo/SonarTsPlugin/issues

Compatibility: SQ 5.6+ (demo sites available: v5.6.6, v6.0, v6.1, v6.2, v6.3), JRE 1.8+, tslint 2.4+

Release notes: https://github.com/Pablissimo/SonarTsPlugin/releases/tag/v1.1.0

Download: https://github.com/Pablissimo/SonarTsPlugin/releases/download/v1.1.0/sonar-typescript-plugin-1.1.0.jar

Example projects (also used as an integration test): https://github.com/Pablissimo/SonarTsPlugin/tree/master/samples

Quality gate: https://sonarqube.com/dashboard?id=com.pablissimo.sonar%3Asonar-typescript-plugin

The plugin is currently listed on the SonarQube.org 'Other Plugins' page but I'm keen at some stage to see it added to the Update Centre if possible, so am open to feedback on how it looks, works and is packaged just now to get it there. I anticipate there might be a few issues to resolve, so this may not be the first version that makes it to the Update Centre, but you've got to start somewhere!

Any feedback or guidance much appreciated!

Thanks in advance,

Paul

[G. Ann Campbell]

Hi Paul,

I need to have some internal discussions about this before I can give you an answer, but I didn't want to just leave you hanging. I think we haven't made a secret of the fact that we're planning to offer TypeScript coverage this year. On the face of it, that presents a conflict, but since your plugin leverages TsLint, I think it can easily fit into the External Analyzers category. However analyzers in that category are typically named for the analyzer, not the language. Plus, we'd prefer to reserve the Sonar[Language] pattern for SonarSource analyzers.

So, it will probably make things easier going forward if you would re-christen the plugin ("TsLint"?), and perhaps use the sonar.pluginKey property to give it a different plugin key (used by the Update Center) without needing to re-set the artifact id.

One other note on this. I haven't tested your plugin yet but I did see that you don't appear to be using the feedback period convention yet. That is a requirement for the update center, so I would need to see that happen on your next version.

:-)

Ann

[Paul O'Neill]

Ta for reply, I had wondered when an official plugin would appear! A team of people writing a proper analyser'll be much better than my free-time cobbling so look forward to that.

If I can change the pluginKey without it breaking existing installs then that seems easy enough to do. Renaming the repository and build artifact name should be easy too.

However - given the the plugin may have an overlapping feature set with an official one (line-counting, code-coverage and what was planned to be duplication calculation) I'm wondering if I should either split it into two plugins or just not have it in the Update Center until the specs of the official one are out to avoid confusion? I might hold fire until you guys have something in the wild so that I'm not duplicating effort.

[G. Ann Campbell]

Hi Paul,

Thanks for being open to changes. 

As for re-keying the plugin, that key is used by the update center to understand when upgrades to existing plugins are available. If you were to re-key before entry to the UC (still pending internal discussions, BTW) then existing users wouldn't be affected at that upgrade because they wouldn't be using the UC to get it. Theoretical future upgrades through the UC should then be entirely transparent.

Regarding duplicate functionality, that had crossed my mind too. Two plugins trying to save the same measures on the same files would cause problems (fail the analysis IIRC). But it feels really premature to plan that bridge crossing.

:-)

Ann

---

G. Ann CAMPBELL | SonarSource

Product Manager

http://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/3O9vDYozu-Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/68bbf38a-0a65-4b19-9d73-7b11bd0eef25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[G. Ann Campbell]

Hi Paul,

I haven't tested your plugin yet, but assuming it tests out fine it looks like you're good to go if you make the changes we discussed and publish an RC for your next version. You don't have to publish it here necessarily, but you do need to be able to point me to a Request For Feedback thread somewhere.

:-)

Ann