# SonarJS is the analyzer that turns JavaScript rules into ESLint findings > SonarJS is SonarSource's static analyzer for JavaScript, TypeScript and CSS, built on pattern matching and control flow analysis, with 534 JavaScript rules and 553 TypeScript rules. The same rule implementation also ships as an ESLint plugin, so the same findings can run in your editor or in a SonarQube server analysis. **SonarSource/SonarJS** — SonarSource Static Analyzer for JavaScript and TypeScript - Repository: https://github.com/SonarSource/SonarJS - Website: https://community.sonarsource.com/ - Stars: 1,302 · Forks: 194 - Language: TypeScript - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/sonarsource-sonarjs ## What the analyzer covers SonarJS inspects JavaScript, TypeScript and CSS for bugs, vulnerabilities and maintainability issues, and the findings appear in SonarQube for the IDE and in project analysis on SonarQube Server or SonarQube Cloud. The README adds a point that has become a requirement rather than a feature: SonarJS analyzes developer-written and AI-generated code, giving teams a consistent way to verify changes before they reach production. The rule counts are the clearest measure of coverage, with 534 JavaScript rules, 553 TypeScript rules and 44 CSS rules, and the analysis is built on advanced rules based on pattern matching and control flow analysis, which is the difference between a linter and an analyzer. ## Language and framework coverage The compatibility statement is ECMAScript 2015 to 2020, which is worth checking against your codebase because it is a hard boundary rather than a moving target. On top of that there is React JSX, Flow, Vue and AWS lambda functions support for JavaScript and TypeScript, and for CSS the analyzer handles CSS, SCSS, SASS and Less, as well as style blocks inside HTML and VueJS files. That last detail matters more than it looks, because a lot of real style code lives inside components rather than in separate stylesheets, and a tool that ignores it leaves a large blind spot. The metrics side covers complexity and number of lines, and there is import of test coverage reports, plus import of ESLint, TSLint and Stylelint issues. ## The same rules run in ESLint The line that changes how you would adopt this is the note that the repository now hosts eslint-plugin-sonarjs, the plugin for ESLint. The package lives under `packages/analysis/src/jsts/rules/`, which tells you the implementation is shared rather than duplicated: the ESLint plugin is a wrapper around the same rule code that SonarQube runs. The practical effect is that a rule can be evaluated in the editor, in a pre-commit hook and in a server analysis without the findings diverging, which is the usual complaint about running a linter and a scanner side by side. The README also states the licence situation for this package specifically, which is a legal change and not only a technical one. ## Building it needs four tools and two commands The development prerequisites are a JDK 21, Node.js 22 or newer, npm 8 or newer and Maven 3.8 or newer. The normal local build installs the Node dependencies and then runs the Maven build: ```shell npm ci mvn install ``` The distinction between the two paths matters. For normal local development you build with the tracked rule metadata already present in the checkout, which is the fast path. To refresh the RSPEC rule data before a clean rebuild there is a separate command, since the rule specification comes from a shared source of truth: ```shell npm run rspec:refresh mvn clean install ``` The `rspec:refresh` script is a Maven invocation with the `rspec-refresh` profile that processes resources while skipping tests, and the README notes that the package.json intentionally keeps only Node-oriented workflows plus this one explicit entrypoint, with Maven builds meant to be invoked directly. So the Node toolchain and the Maven build are two separate worlds that meet in the analyzer, and knowing which side owns a task saves time. ## The repository carries the tooling for a large rule set The top level of the repository shows how much of the effort is about maintaining rules rather than analysing code. There is a `tools/` directory with scripts for the individual jobs, and the package manifest names them: `new-rule` runs a tsx script that scaffolds a new rule, `generate-meta` generates the rule metadata, `validate-quickfix` validates the quick fixes, and `generate-java-rule-classes` generates the Java rule classes from the TypeScript ones. There is a `ruling` script that runs the test ruling projects, a caching variant of it that enables a filesystem cache for the ruling tests, and a `ruling-sync` script that syncs the expected results into the `its/` directory. The `its/` directory is the integration test suite, `packages/` holds the analysis packages, `licenses/` and `license-management.mjs` handle the per-file licence headers, and `knip.json` and `mise.toml` handle unused dependency detection and tool versions. ## The licence changed, and the details are per file The licensing section is the part of this repository that most needs reading carefully, because the change is recent and the details are not uniform. The copyright runs 2011 to 2024 SonarSource, and the README states that SonarQube analyzers released after November 29 2024, including patch fixes for prior versions, are published under the Sonar Source-Available License Version 1, with the link to the licence file. The README then says to see the individual files for details specifying the licence applicable to each file, and that files subject to the SSALv1 will be noted in their headers. That is a per-file determination, which means the licence of a given rule or a given part of the analyzer depends on when it was written, and it is not something a single licence file can tell you at a glance. ## Conclusion Adopt SonarJS when you want a rule set that is more thorough than a linter but still runnable inside your editor, since the same rules are available as an ESLint plugin and in SonarQube. Do not adopt it expecting a permissive licence, because analyzers released after November 29 2024 are published under the Sonar Source-Available License. Verify first which version you are taking and what licence applies to it, and read the individual file headers, because the repository mixes the older copyright terms with the new licence and the applicable terms are stated per file. ## FAQ ### What does SonarJS analyze? It inspects JavaScript, TypeScript and CSS for bugs, vulnerabilities and maintainability issues, and it is compatible with ECMAScript 2015 to 2020. Support also covers React JSX, Flow, Vue and AWS lambda functions, plus CSS, SCSS, SASS and Less including style blocks inside HTML and VueJS files. ### Can SonarJS rules run in ESLint? Yes. The repository hosts eslint-plugin-sonarjs under packages/analysis/src/jsts/rules, so the plugin shares the rule implementation with the analyzer rather than duplicating it, and findings can appear in the editor and in a SonarQube analysis. ### How do I build SonarJS from source? You need JDK 21, Node.js 22 or newer, npm 8 or newer and Maven 3.8 or newer. Run `npm ci` and then `mvn install` for normal development, or `npm run rspec:refresh` followed by `mvn clean install` to refresh the RSPEC rule data first. ### What licence applies to SonarJS? SonarQube analyzers released after November 29 2024, including patch fixes for prior versions, are published under the Sonar Source-Available License Version 1, with the terms in the LICENSE.txt file. The applicable licence is specified per file, and files under SSALv1 are noted in their headers. ### Where do I report bugs or request features for SonarJS? On the SonarQube Community Forum, with the details of the request, a code reproducer and the versions of the projects you use. New features are also requested as a forum thread first, even if you intend to implement the change yourself. ## Sources - [Issues](https://github.com/SonarSource/SonarJS/issues) - [Project website](https://community.sonarsource.com/) - [README](https://github.com/SonarSource/SonarJS/blob/master/README.md) - [Releases](https://github.com/SonarSource/SonarJS/releases) - [SonarSource/SonarJS on GitHub](https://github.com/SonarSource/SonarJS) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sonarsource-sonarjs