# JavaScript/TypeScript/CSS

### Prerequisites <a href="#prerequisites" id="prerequisites"></a>

In order to analyze JavaScript, TypeScript, or CSS code, you need to have supported version of Node.js installed on the machine running the scan; the recommended versions are v16 and v18. We recommend using the [active LTS version of Node.js](https://nodejs.org/en/about/releases/) for optimal stability and performance. v14.17 is still supported, but it has already reached end-of-life and is deprecated.

If `node` is not available in the `PATH`, you can use property `sonar.nodejs.executable` to set an absolute path to Node.js executable.

If you have a community plugin for CSS analysis installed on your SonarQube instance it will conflict with analysis of CSS, so it should be removed.

### Language-specific properties <a href="#language-specific-properties" id="language-specific-properties"></a>

Discover and update the JavaScript/TypeScript [analysis-parameters](https://docs.sonarsource.com/sonarqube-server/10.1/analyzing-source-code/analysis-parameters "mention") in **Administration > General Settings > Languages > JavaScript/TypeScript**.

Discover and update the CSS [analysis-parameters](https://docs.sonarsource.com/sonarqube-server/10.1/analyzing-source-code/analysis-parameters "mention") in **Administration > General Settings > CSS**.

### Supported frameworks, versions and languages <a href="#supported" id="supported"></a>

* ECMAScript 3, 5, 2015, 2016, 2017, 2018, 2019, 2020, 2021 and 2022
* TypeScript 5.0
* React JSX, Vue.js, Angular
* Flow
* CSS, SCSS, Less, also ‘style’ inside PHP, HTML and VueJS files

### Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>

#### Slow or unresponsive analysis <a href="#slow-or-unresponsive-analysis" id="slow-or-unresponsive-analysis"></a>

On a big project, more memory may need to be allocated to analyze the project. This would be manifested by analysis getting stuck and the following stack trace might appear in the logs

```css-79elbk
ERROR: Failed to get response while analyzing [file].ts
java.io.InterruptedIOException: timeout
```

You can use `sonar.javascript.node.maxspace` property to allow the analysis to use more memory. Set this property to `4096` or `8192` for big projects. This property should be set in `sonar-project.properties` file or on command line for scanner (with `-Dsonar.javascript.node.maxspace=4096`).

#### Default exclusions for JS/TS <a href="#default-exclusions-for-jsts" id="default-exclusions-for-jsts"></a>

By default, analysis will exclude files from dependencies in usual directories, such as `node_modules`, `bower_components`, `dist`, `vendor`, and `external`. It will also ignore `.d.ts` files. If for some reason analysis of files in these directories is desired, it can be configured by setting `sonar.javascript.exclusions` property to empty value, i.e. `sonar.javascript.exclusions=""`, or to comma separated list of paths to be excluded. This property will exclude only JavaScript/TypeScript files, while `sonar.exclusions` property will exclude all files. `sonar.exclusions` property should be preferred to configure general exclusions for the project.

#### Detection of code bundles <a href="#detection-of-code-bundles" id="detection-of-code-bundles"></a>

The analyzer will attempt to detect bundled code or generated code. This means code that was automatically transformed and optimized with tools such as Webpack and similar. We consider generated code out of scope of the analysis since developers are not able to act upon the findings in such code. Whenever generated code is detected, the analysis will print a log message: once per the whole project on `INFO` level, and for each file on the `DEBUG` level. If you want to opt-in for analyzing the generated code or in case the detection is incorrect, you can disable it by setting `sonar.javascript.detectBundles=false`.

#### Custom rules for JS/TS <a href="#custom-rules-for-jsts" id="custom-rules-for-jsts"></a>

Custom rules are not supported by the analyzer. As an alternative we suggest you to have a look at [ESLint](https://eslint.org/docs/developer-guide/). It provides custom rules that you can then import thanks to the [importing-third-party-issues](https://docs.sonarsource.com/sonarqube-server/10.1/analyzing-source-code/importing-external-issues/importing-third-party-issues "mention") feature.

### Related Pages <a href="#related-pages" id="related-pages"></a>

* [importing-third-party-issues](https://docs.sonarsource.com/sonarqube-server/10.1/analyzing-source-code/importing-external-issues/importing-third-party-issues "mention") (ESLint, TSLint, StyleLint)
* [overview](https://docs.sonarsource.com/sonarqube-server/10.1/analyzing-source-code/test-coverage/overview "mention") (LCOV format)
* [SonarJS plugin for ESLint](https://github.com/SonarSource/eslint-plugin-sonarjs)
* [adding-coding-rules](https://docs.sonarsource.com/sonarqube-server/10.1/extension-guide/adding-coding-rules "mention")
