#Basic setup example This sample project can be analysed by SonarQube to demonstrate:
- Linting information from
tslint, configured via atslint.jsonfile - Code coverage metrics from an LCOV file
You can see a live example of the results of analysing this project at https://sonar.pablissimo.com.
##Building and analysing
- Run
npm installfrom the cloned repo folder - Run
npm testto regenerate code coverage information- You don't need to perform this step, a coverage file is already checked into the repository
To analyse with SonarQube just run sonar-scanner -X from the cloned repo folder.
- The -X flag will give us diagnostic information during the run, so you can see what the plugin is up to
##Breaking down the sonar-project.properties file
The sample has a sonar-project.properties file that controls how the analysis gets run. We haven't specified anything here that isn't its default or automatically detected - these are explained under the table.
| Line | Description |
|---|---|
| sonar.projectKey=com.pablissimo.sonar:basic-setup | Unique string that identifies this project to SonarQube, differentiating it from any other project that's being analysed by the same server |
| sonar.projectName=Basic project setup example | Name of the project, which will show in the SonarQube admin interface |
| sonar.projectVersion=1.0 | Version of the project |
| sonar.sources=./src | The path to the source code for your project - essentially describing the files to be analysed. Specified relative to the sonar-project.properties file. |
| sonar.sourceEncoding=UTF-8 | The encoding of your source files - typically UTF-8 is fine, unless you know you're using a different encoding |
| sonar.exclusions=node_modules/** | The files that should be excluded from analysis - here, we don't want to include anything in the node_modules folder as it's full of TypeScript and JavaScript that's got nothing to do with us and would muddy the analysis |
| sonar.tests=./test | The path to any test code you have for your project, which will be excluded when calculating code coverage metrics - but these files are still analysed by the plugin for linting issues |
| sonar.ts.coverage.lcovReportPath=coverage/lcov.info | The path to an LCOV-format file describing code coverage for your project. Typically generated by tools like Karma, Istanbul (with Istanbul-remap), Chutzpah etc |
Several settings are automatically detected (and you'll see these listed in the LCOV output):
- The path to
tslintis automatically detected as within the node_modules folder - The location to the
tslint.jsonfile that configures tslint is automatically assumed to be the same folder as thesonar-project.propertiesfile