This version of the SonarQube documentation is no longer maintained. It relates to a version of SonarQube that is not active.

See latest version
Start Free
10.2 | Analyzing source code | Languages | JavaScript/TypeScript/CSS

Was this page helpful?


On this page


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 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

Discover and update the JavaScript/TypeScript properties in Administration > General Settings > Languages > JavaScript/TypeScript.

Discover and update the CSS properties in Administration > General Settings > CSS.

Supported frameworks, versions and languages

  • 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


Slow or unresponsive analysis

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

ERROR: Failed to get response while analyzing [file].ts 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 file or on command line for scanner (with -Dsonar.javascript.node.maxspace=4096).

Default exclusions for JS/TS

By default, analysis will exclude files from dependencies in usual directories, such as node_modulesbower_componentsdistvendor, 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

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

Custom rules are not supported by the analyzer. As an alternative we suggest you to have a look at ESLint. It provides custom rules that you can then import thanks to the External issues feature.

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License