comparison

SonarQube vs ESLint: Code Quality Platform vs JavaScript Linter (2026)

SonarQube vs ESLint compared - static analysis scope, language support, quality gates, CI/CD integration, and whether you need both or can pick one.

Published:

Last Updated:

Quick Verdict

SonarQube static analysis tool homepage screenshot
SonarQube homepage

This comparison is unusual because SonarQube and ESLint are not really competitors - they are complementary tools that most professional teams should use together. Comparing them head-to-head is like comparing a full-body MRI machine to a stethoscope. Both check your health, but they operate at fundamentally different levels of depth, scope, and context.

ESLint is a JavaScript and TypeScript linter. It runs in your editor, catches code style violations and potential bugs in real time, and enforces team coding standards through configurable rules and plugins. It is free, open source, and used by virtually every JavaScript project in existence.

SonarQube is a multi-language code quality and security platform. It runs in your CI/CD pipeline, analyzing your entire codebase across 30+ languages for bugs, security vulnerabilities, code smells, duplication, and coverage gaps. It enforces quality gates that block non-compliant code from being merged. The Community Build is free and self-hosted. Commercial editions add branch analysis, security scanning, and enterprise features.

The short answer: Use ESLint in development (editor + pre-commit). Use SonarQube in CI/CD (pipeline analysis + quality gates). They catch different things at different stages, and the overlap between them strengthens rather than weakens your quality process. If you must pick exactly one, ESLint is essential for JavaScript/TypeScript teams and SonarQube is optional - but you lose significant security and cross-language coverage by skipping SonarQube.

At-a-Glance Comparison

CategorySonarQubeESLint
TypeCode quality and security platformJavaScript/TypeScript linter
Languages30+ (including Java, Python, C#, Go, C++, COBOL)JavaScript, TypeScript (via plugins: JSX, Vue, Svelte)
Total rules6,500+ across all languages~300 core rules + thousands via plugins
JS/TS rules~500+ proprietary rules~300 core + ecosystem plugins
Runs inCI/CD pipeline (server-side analysis)Editor, CLI, pre-commit hooks, CI
Real-time editor feedbackVia SonarLint IDE pluginNative - runs as you type
Quality gatesYes - configurable, PR-blockingNo built-in quality gates
Security scanningYes - SAST with taint analysis (Developer+)Limited - basic patterns via plugins
Code coverage trackingYesNo
Duplication detectionYesNo
Technical debt trackingYes - remediation time estimatesNo
Custom rulesQuality Profiles (centrally managed)Fully programmable (write custom rules in JS)
Plugin ecosystemSonarSource-curatedMassive open-source ecosystem (2,900+ npm packages)
ConfigurationWeb dashboard (Quality Profiles)Config files (eslint.config.js or .eslintrc)
PricingFree Community Build; paid from EUR 30/monthCompletely free and open source
Self-hostedYes (core deployment model)N/A - runs locally by design
CI/CD integrationRequired for core functionalityOptional - can run in CI but not required

What Is SonarQube?

SonarQube is a code quality and security analysis platform developed by SonarSource, a Swiss company founded in 2008. It is the most widely adopted static analysis platform in the industry, used by over 7 million developers across 400,000+ organizations. The platform provides 6,500+ deterministic analysis rules covering bugs, code smells, security vulnerabilities, and security hotspots across 35+ languages in its commercial editions.

SonarQube operates as a server-side analysis engine. Code is scanned during the CI/CD pipeline using the SonarScanner CLI tool, and results are reported to a central SonarQube instance (either self-hosted or cloud-hosted) where they are displayed on project dashboards, tracked over time, and enforced through quality gates. The defining feature of SonarQube is its quality gate system - automated conditions that block code from being merged when it fails defined quality thresholds for coverage, bugs, vulnerabilities, duplication, or technical debt.

For JavaScript and TypeScript specifically, SonarQube includes approximately 500+ proprietary rules that cover bugs, code smells, security vulnerabilities, and security hotspots. These rules are distinct from ESLint’s rules - they are implemented independently by SonarSource and often detect different patterns. The Developer Edition and above include taint analysis for JavaScript, which tracks user input through the application to detect injection vulnerabilities spanning multiple files - something ESLint fundamentally cannot do.

For a detailed breakdown of SonarQube’s capabilities, see our SonarQube review. For pricing details, see our SonarQube pricing guide.

What Is ESLint?

ESLint is a pluggable linting tool for JavaScript and TypeScript, originally created by Nicholas Zakas in 2013. It is maintained by the OpenJS Foundation and is the de facto standard linter for the JavaScript ecosystem. ESLint analyzes source code to find problematic patterns, enforce coding conventions, and catch potential bugs before runtime.

ESLint runs locally - in the developer’s editor as a real-time extension, as a CLI command during development, in pre-commit hooks via tools like Husky and lint-staged, and optionally in CI/CD pipelines. The key distinction is that ESLint provides immediate, in-editor feedback. When a developer writes if (x = 5) instead of if (x === 5), ESLint highlights the issue instantly with a red underline and an explanation. This tight feedback loop is ESLint’s core value proposition - catching issues at the moment they are written, not minutes or hours later in a CI pipeline.

ESLint’s rule system is infinitely extensible. The core package includes approximately 300 rules, but the ecosystem contains thousands more through community plugins. Popular plugins include eslint-plugin-react (React-specific rules), eslint-plugin-vue (Vue.js rules), @typescript-eslint (TypeScript rules), eslint-plugin-import (module import/export rules), eslint-plugin-security (basic security patterns), and eslint-plugin-jsx-a11y (accessibility rules). Teams can also write entirely custom rules in JavaScript, making ESLint adaptable to any coding standard or convention.

In 2024, ESLint completed its migration to the “flat config” system (eslint.config.js), replacing the legacy .eslintrc format. The flat config simplifies configuration, makes rule resolution more predictable, and is now the default for new projects. ESLint 9.x dropped support for the legacy format entirely.

Feature Breakdown

Scope of Analysis

This is the most fundamental difference between the two tools, and understanding it is critical to making the right decision.

ESLint operates at the single-file level. It parses one JavaScript or TypeScript file at a time, builds an Abstract Syntax Tree (AST), and runs rules against that AST. Rules can inspect variable declarations, function calls, control flow patterns, import statements, and other syntactic elements within a single file. ESLint does not understand the relationships between files - it cannot track a variable defined in one file and used in another, follow data flow across module boundaries, or understand how components compose in a multi-file application.

SonarQube operates at the project level. It analyzes the entire codebase in a single pass, building a comprehensive model that includes cross-file relationships, data flow paths, and dependency graphs. This project-level analysis enables capabilities that single-file linting cannot provide. SonarQube can detect a user input received in a route handler (file A) that flows through a service layer (file B) and reaches a database query (file C) without sanitization - a classic SQL injection vulnerability. ESLint, analyzing each file independently, would see nothing wrong in any of the three files individually.

SonarQube covers 30+ programming languages. For teams working across JavaScript, Python, Java, Go, C#, or any other language in their stack, SonarQube provides consistent quality analysis across the entire codebase. ESLint is limited to JavaScript and TypeScript (with JSX, Vue, and Svelte through plugins). A team building a Node.js backend with a Python ML pipeline and a Go microservice would need ESLint for the Node.js code, Pylint or Ruff for the Python code, and golangci-lint for the Go code - or they could use SonarQube as a single platform covering all three.

Rule Customization and Configuration

ESLint’s customization model is developer-centric. Rules are defined in configuration files (eslint.config.js) that live in the repository alongside the code. Developers can enable, disable, or configure individual rules. They can extend shared configurations (like eslint-config-airbnb or eslint-config-standard) to adopt community coding standards. They can write entirely custom rules in JavaScript by traversing the AST. The configuration is version-controlled, reviewed in pull requests, and deployed with the code. This gives individual teams maximum control over their linting rules.

The plugin ecosystem is ESLint’s secret weapon. With over 2,900 ESLint-related packages on npm, there is a plugin for almost every framework, library, and coding convention imaginable. React, Vue, Angular, Svelte, Next.js, Nuxt, Astro, Node.js, Express, testing libraries (Jest, Vitest, Cypress, Playwright) - all have dedicated ESLint plugins that enforce framework-specific best practices. This level of ecosystem breadth is unmatched by any other tool.

SonarQube’s customization model is centrally managed. Rules are configured through Quality Profiles in the SonarQube dashboard - a web-based interface where administrators enable, disable, and configure rules for each language. Quality Profiles are applied to projects through the SonarQube server, ensuring that every project in the organization uses the same standards (unless explicitly overridden). This centralized management is valuable for enterprise teams that need consistent standards across hundreds of projects managed by different teams. An engineering manager can define the organization’s quality standards once and have them applied everywhere.

The trade-off is clear. ESLint gives individual teams maximum flexibility to customize their linting rules for their specific project. SonarQube gives organizations centralized control to enforce consistent standards across all projects. For a startup with one team and one repository, ESLint’s approach is ideal. For an enterprise with fifty teams and two hundred repositories, SonarQube’s centralized management prevents the fragmentation that occurs when every team defines its own rules.

Quality Gates

Quality gates are where SonarQube provides a capability that ESLint simply does not offer.

A SonarQube quality gate is a set of conditions that code must meet before it can be merged or deployed. Typical conditions include minimum code coverage percentage on new code, zero new bugs above a certain severity, duplication percentage below a threshold, and security vulnerability count at zero. When a pull request fails the quality gate, SonarQube posts the failure to the PR through PR decoration on GitHub, GitLab, Bitbucket, or Azure DevOps. Teams configure branch protection rules to require the SonarQube check to pass, creating an automated enforcement mechanism.

ESLint can block a build by returning a non-zero exit code when errors are found, but this is a binary pass/fail based on rule violations - not a multi-dimensional quality gate. ESLint has no concept of code coverage, duplication, or technical debt. It cannot enforce “new code must have at least 80% coverage” or “no new security vulnerabilities” because those metrics are outside its scope. Teams that want quality gate enforcement need SonarQube (or a comparable platform like Codacy or DeepSource).

For teams that have experienced the frustration of code quality slowly degrading over time despite having a linter in place, quality gates are the missing piece. ESLint prevents individual bad patterns. Quality gates prevent systemic quality degradation.

IDE Integration

ESLint’s IDE integration is native and seamless. The ESLint VS Code extension is installed on over 30 million VS Code instances. It runs ESLint in the background as you type, highlighting issues with red and yellow underlines, providing fix suggestions through the quick-fix menu, and optionally auto-fixing issues on save. The experience is instantaneous - there is zero delay between writing code and seeing feedback. This real-time integration is ESLint’s most valuable feature for day-to-day development. Extensions are also available for JetBrains IDEs (WebStorm, IntelliJ), Vim/Neovim, Sublime Text, and virtually every other editor.

SonarQube’s IDE integration is through SonarLint. SonarLint is a free plugin for VS Code, JetBrains IDEs, Eclipse, and Visual Studio. It runs a subset of SonarQube rules locally in the editor, providing real-time feedback similar to ESLint. The key feature is “connected mode” - when connected to a SonarQube instance, SonarLint synchronizes the team’s Quality Profile so that rules shown in the IDE match exactly what the CI pipeline enforces. This eliminates the frustrating cycle of pushing code, waiting for CI, finding SonarQube violations, and pushing fixes.

The practical difference is that ESLint runs natively with zero configuration in most editors (especially VS Code with the ESLint extension), while SonarLint requires connecting to a SonarQube instance to get the synchronized experience. For JavaScript and TypeScript development, ESLint’s IDE experience is faster, more responsive, and more deeply integrated. SonarLint adds value by surfacing SonarQube-specific rules that ESLint does not cover - particularly security rules and cross-file analysis patterns.

The best setup is both. Run ESLint in the editor for instant linting feedback. Run SonarLint in connected mode for SonarQube-specific rules. The two extensions do not conflict.

CI/CD Integration

ESLint in CI/CD is straightforward but limited. Add npx eslint . (or your configured lint command) to your CI pipeline, and it will fail the build if any ESLint errors are found. This is a binary gate - pass or fail. ESLint does not post inline PR comments, does not provide quality metrics beyond pass/fail, and does not track trends over time. Many teams run ESLint in CI as a safety net for developers who might skip the editor extension, but the CI step provides the same results as the editor - just delayed.

SonarQube is designed for CI/CD integration. The SonarScanner runs as a dedicated CI step, analyzing the entire codebase and reporting results to the SonarQube server. Results appear as PR decoration (inline comments and quality gate status on the pull request), dashboard updates (project-level metrics and trends), and branch analysis (comparing the current branch against the target branch to show what changed). The CI/CD integration is where SonarQube delivers its core value - the analysis happens at the project level, quality gates enforce standards, and the results persist in a central dashboard for long-term tracking.

For teams that want to go beyond “did the linter pass?” and answer questions like “what is our code coverage trend?”, “how much technical debt did we add this sprint?”, and “are there any security vulnerabilities in this PR?” - SonarQube’s CI/CD integration provides answers that ESLint cannot.

Security Rules

ESLint’s security coverage is minimal and pattern-based. Plugins like eslint-plugin-security detect common anti-patterns such as use of eval(), innerHTML assignments, child_process.exec() with unsanitized input, and SQL string concatenation. These rules catch the most obvious security mistakes but do not perform data flow analysis. If a developer wraps the dangerous call behind two layers of abstraction, ESLint will not trace the input back to its source to determine whether it is user-controlled. This is a fundamental limitation of single-file, AST-based analysis.

SonarQube’s security coverage is substantially deeper. The platform includes approximately 1,000 security-focused rules covering OWASP Top 10, CWE Top 25, and SANS Top 25 vulnerability categories. The Developer Edition and above include taint analysis - tracking data flow from user-controlled sources (HTTP request parameters, form inputs, URL query strings) through the application to dangerous sinks (database queries, command execution, file operations, HTML rendering). Taint analysis can follow data across function calls, module boundaries, and even framework-specific patterns (like Express middleware chains or React component props). This catches injection vulnerabilities that no amount of ESLint rules can detect.

SonarQube also detects security hotspots - code patterns that are not necessarily vulnerable but require human review to confirm safety. Examples include cryptographic operations that might use weak algorithms, authentication logic that might have bypass conditions, and cookie configurations that might lack security flags. This review-oriented approach is valuable for security-conscious teams that want to systematically audit potentially risky code.

For serious JavaScript security scanning, teams should pair ESLint (for obvious anti-patterns) with either SonarQube (for taint analysis and cross-file security rules) or a dedicated SAST tool like Semgrep or Snyk Code. ESLint alone is not sufficient for security assurance.

Code Coverage, Duplication, and Technical Debt

These are dimensions where SonarQube provides capabilities that ESLint does not address at all.

Code coverage: SonarQube parses coverage reports from testing frameworks (Jest, Vitest, Mocha, and others) and displays coverage metrics on the project dashboard. It tracks coverage over time, highlights which lines are covered and which are not, and can enforce minimum coverage on new code through quality gates. ESLint has no coverage functionality.

Duplication detection: SonarQube identifies copy-pasted code blocks across the codebase, calculates a duplication percentage, and tracks it over time. Duplication is one of the most common sources of maintenance burden - when duplicated code needs to change, every copy must be found and updated. ESLint has no duplication detection.

Technical debt: SonarQube quantifies technical debt as estimated remediation time - the total engineering hours required to fix all identified issues. This metric is tracked over time and broken down by severity, category, and file. Engineering managers use it to answer “how much effort would it take to clean up our codebase?” with a concrete number. ESLint has no concept of technical debt quantification.

These features make SonarQube a platform for managing code health at the organizational level, while ESLint remains a tool for individual code quality enforcement at the file level.

Pricing

ESLint Pricing

ESLint is completely free. There is no paid tier, no enterprise edition, no per-user or per-repo licensing. The core package, all official plugins, the VS Code extension, and the flat config system are free and open source under the MIT license. This applies to individuals, startups, and Fortune 500 companies equally.

The total cost of ESLint is zero dollars, forever. This is one of the strongest arguments for ESLint as the foundation of any JavaScript linting strategy - there is no financial risk and no pricing surprises.

SonarQube Pricing

PlanPriceKey Features
Community Build (self-hosted)FreeOpen source, 20+ languages, basic quality gates, no branch/PR analysis
Cloud FreeFreeUp to 50K LOC, 30 languages, branch/PR analysis, PR decoration
Cloud TeamFrom EUR 30/monthFull branch/PR analysis, quality gates on PRs, SonarLint connected mode
Developer Edition (Server)From ~$2,500/year35+ languages, branch/PR analysis, PR decoration, taint analysis
Enterprise Edition (Server)From ~$20,000/yearPortfolio management, compliance reports, legacy language support, Advanced Security add-on
Data Center Edition (Server)CustomHigh availability, horizontal scaling

For a detailed pricing breakdown with cost scenarios for different team sizes, see our SonarQube pricing guide.

Cost Comparison for JavaScript Teams

For teams working exclusively in JavaScript and TypeScript, the cost equation is straightforward:

  • ESLint: $0/year. Always.
  • SonarQube Community Build (self-hosted): $0/year for the license, plus infrastructure and maintenance costs (server, database, DevOps time).
  • SonarQube Cloud Free: $0/year for up to 50K lines of code. Sufficient for small projects and evaluations.
  • SonarQube Cloud Team: From EUR 30/month (~$390/year) for small codebases. Scales with lines of code.
  • SonarQube Developer Edition (self-hosted): From ~$2,500/year. Includes taint analysis and PR decoration.

The decision is not ESLint or SonarQube from a cost perspective. ESLint is free, so you always use it. The question is whether to add SonarQube on top of ESLint, and whether the additional coverage justifies the cost and operational overhead.

Use Cases

When ESLint Alone Is Enough

Small JavaScript/TypeScript projects with simple security requirements. If you are building a marketing site, an internal tool, or a side project that does not handle sensitive user data, ESLint with a good configuration (like eslint-config-airbnb or @antfu/eslint-config) combined with Prettier for formatting covers your quality needs. Adding SonarQube would be over-engineering.

Solo developers and very small teams (1-3 people). The operational overhead of setting up and maintaining SonarQube - even SonarQube Cloud - may not be justified when every developer is already running ESLint in their editor. The quality gate enforcement matters less when the same two or three people are writing and reviewing all the code.

Open-source libraries and packages. Most open-source JavaScript packages use ESLint (and often Prettier) as their entire quality toolchain. The scope is typically narrow (one package, one language), the contributors are experienced, and the code undergoes thorough review. SonarQube’s cross-file analysis and quality gates add less value in this context.

When You Need SonarQube in Addition to ESLint

Multi-language projects. If your team writes JavaScript alongside Python, Java, Go, C#, or any other language, SonarQube provides consistent quality analysis across the entire stack. Without SonarQube, you need a separate linter for each language (ESLint for JS, Pylint for Python, golangci-lint for Go) with no unified dashboard, no cross-project quality gates, and no centralized trend tracking.

Applications handling sensitive data. If your JavaScript application processes user credentials, financial data, healthcare records, or other sensitive information, ESLint’s security plugins are insufficient. SonarQube’s taint analysis can detect injection vulnerabilities that cross file boundaries - the kind of security bugs that cause data breaches. For security-critical applications, SonarQube’s Developer Edition (or a dedicated SAST tool like Semgrep) is strongly recommended.

Growing teams (10+ developers). As teams grow, code quality becomes harder to enforce through culture alone. New hires bring different standards. Code review thoroughness varies. Technical debt accumulates unevenly. SonarQube’s quality gates create an automated enforcement layer that maintains standards regardless of who is writing or reviewing the code. The investment in SonarQube pays off when you no longer need to rely on senior developers catching every issue in review.

Enterprise engineering organizations. If your organization has dozens of repositories across multiple teams and needs to maintain consistent quality standards, report on technical debt to leadership, and comply with security regulations (OWASP, CWE, SANS), SonarQube’s centralized management, portfolio dashboards, and compliance reporting are essential. ESLint operates at the project level and has no organizational-level features.

Teams that need code coverage enforcement. If you want to enforce “new code must have at least 80% test coverage” as a hard requirement on every pull request, SonarQube’s quality gates provide this capability. ESLint has no awareness of test coverage.

Do You Need Both SonarQube and ESLint?

For most professional JavaScript and TypeScript teams, yes - you should use both. The tools are not redundant. They operate at different layers of the development workflow and catch different categories of issues.

ESLint provides the fast feedback loop. Issues appear in the editor as you type. Fix them before you even save the file. This immediate feedback is the most effective way to prevent code style violations, common bugs, and convention deviations from ever entering the codebase. No CI pipeline, no server, no delay.

SonarQube provides the deep analysis layer. Cross-file security scanning, quality gate enforcement, code coverage tracking, duplication detection, and technical debt quantification happen during the CI/CD pipeline. These capabilities require project-level analysis that single-file linting cannot provide.

The overlap is intentional and beneficial. Yes, some ESLint rules and SonarQube rules catch the same issues. This means issues caught by ESLint in the editor are also caught by SonarQube in CI - providing a safety net for developers who might bypass ESLint (by disabling rules, skipping pre-commit hooks, or using an editor without the ESLint extension). The redundancy is a feature, not a bug.

The workflow looks like this:

  1. Developer writes code. ESLint highlights issues in real time in the editor.
  2. Developer commits code. Pre-commit hook runs ESLint (via lint-staged) and blocks commits with errors.
  3. Developer pushes code. CI pipeline runs SonarQube analysis.
  4. SonarQube posts quality gate results to the pull request. If the gate fails (coverage too low, new bugs found, security vulnerabilities detected), the PR is blocked.
  5. Developer fixes issues, pushes again. Gate passes. PR is merged.

This layered approach catches issues at every stage - editor, commit, push, and PR - with increasing depth of analysis at each layer.

When to Skip SonarQube

The main reasons to skip SonarQube are budget constraints (though the Community Build and Cloud Free tier are free), operational overhead aversion (though Cloud eliminates server management), or genuinely minimal requirements (small team, simple project, no security concerns). If your team writes only JavaScript/TypeScript, has fewer than five developers, builds applications without sensitive data handling, and does not need quality gate enforcement - ESLint plus Prettier is a perfectly adequate toolchain.

Alternatives to Consider

If the SonarQube-plus-ESLint combination does not fit your situation, several alternatives address parts of the equation.

Semgrep is the strongest alternative to SonarQube for security scanning. Its open-source engine provides pattern-based analysis with a massive community rule library. Semgrep Pro adds cross-file and cross-function data flow analysis comparable to SonarQube’s taint analysis. If your primary motivation for evaluating SonarQube is security scanning rather than code quality metrics, Semgrep may be a better fit. It supports JavaScript alongside 30+ other languages and has a free open-source tier.

Codacy is a cloud-native code quality and security platform that packages SAST, SCA, secrets detection, coverage tracking, and AI-powered review at $15/user/month. Codacy embeds ESLint as one of its analysis engines for JavaScript, so you get ESLint analysis plus additional security and quality coverage without running ESLint separately. For teams that want a single platform with minimal setup, Codacy is worth evaluating. See our Codacy vs SonarQube comparison for details.

DeepSource offers 5,000+ analysis rules with an emphasis on low false positive rates and AI-powered auto-fix. At $12/user/month, it is priced below both Codacy and SonarQube’s paid tiers. DeepSource supports JavaScript, TypeScript, Python, Go, Java, Ruby, and other languages. Its PR report cards provide a multi-dimensional quality assessment (bugs, anti-patterns, performance, security, style) that goes beyond simple pass/fail.

Code Climate provides maintainability grading (A-F scores) and test coverage tracking through a lightweight cloud platform. It is simpler than SonarQube but also shallower. For teams that want basic code quality metrics without the depth (or complexity) of SonarQube, Code Climate remains an option - though its investment has slowed in recent years. See our SonarQube vs Code Climate comparison for details.

Biome (not a platform on our site) is the most promising ESLint alternative for teams that want a faster, all-in-one linter and formatter. Built in Rust, Biome runs 10-100x faster than ESLint and combines linting with formatting (replacing both ESLint and Prettier). Its rule set is growing but does not yet match ESLint’s plugin ecosystem breadth. Biome is worth watching as a potential ESLint replacement for new projects.

For a broader view of tools in this space, see our best code quality tools roundup and our SonarQube alternatives guide.

Final Recommendation

The SonarQube vs ESLint question almost always has the same answer: use both.

ESLint is the non-negotiable foundation for any JavaScript or TypeScript project. It is free, universal, instantly integrated into every editor, and catches the vast majority of code style and convention issues at the earliest possible point - while you are writing the code. No other tool provides this speed of feedback for JavaScript development. ESLint plus Prettier plus a good shared configuration (like @antfu/eslint-config or eslint-config-airbnb) gives you a solid baseline that costs nothing and takes minutes to set up.

SonarQube is the recommended addition for teams that need to go beyond linting. If you need security scanning that detects cross-file injection vulnerabilities, quality gates that enforce coverage and complexity standards on pull requests, technical debt tracking with concrete remediation estimates, or consistent analysis across a multi-language codebase - SonarQube is the most mature platform for these capabilities. The Community Build is free for self-hosted deployment, and SonarQube Cloud Free supports up to 50K lines of code at no cost.

For JavaScript/TypeScript-only teams under 5 developers: ESLint + Prettier. Add SonarQube Cloud Free when you want quality gates and coverage tracking.

For JavaScript/TypeScript teams of 5-20 developers: ESLint + Prettier + SonarQube Cloud (Free or Team tier). The quality gates alone justify the setup investment as your team grows.

For multi-language teams of any size: ESLint + Prettier for JavaScript/TypeScript + SonarQube (Cloud or Server) for cross-language analysis. SonarQube is the only tool in the stack that provides a unified quality view across all your languages.

For security-sensitive applications: ESLint + Prettier + SonarQube Developer Edition (for taint analysis) or pair ESLint with Semgrep for deeper SAST coverage. Consider adding Snyk for dependency vulnerability scanning.

For enterprise organizations: ESLint + Prettier + SonarQube Enterprise Edition. Add CodeRabbit for AI-powered PR review. The combination provides linting, deep analysis, security scanning, quality gate enforcement, compliance reporting, and AI-augmented code review across the entire engineering organization.

The tools are not competitors. They are layers in a quality stack. Use ESLint for speed. Use SonarQube for depth. Your codebase will be better for having both.

Frequently Asked Questions

Do I need both SonarQube and ESLint?

In most cases, yes. ESLint and SonarQube are complementary tools that operate at different layers of the development workflow. ESLint runs in your editor and pre-commit hooks, catching code style violations, potential bugs, and enforcing team conventions in real time as you write JavaScript or TypeScript. SonarQube runs in your CI/CD pipeline, analyzing your entire codebase across all languages for bugs, security vulnerabilities, code smells, duplication, and coverage gaps. Using both gives you the fastest possible feedback (ESLint in the editor) and the deepest possible analysis (SonarQube in CI). SonarQube even imports ESLint findings through its sonar-eslint plugin, so the two tools integrate rather than conflict.

Does SonarQube replace ESLint?

No. SonarQube does not replace ESLint. While SonarQube includes its own JavaScript and TypeScript analysis rules - many of which overlap with ESLint rules - it does not run in the editor or provide real-time feedback as you type. SonarQube runs during CI/CD pipeline execution, which means developers would not see issues until after pushing their code. ESLint provides instant, in-editor feedback that catches problems before code is even committed. The two tools serve different purposes at different stages of the development lifecycle, and most professional teams use both.

Does SonarQube use ESLint internally?

SonarQube does not use ESLint as its internal analysis engine for JavaScript and TypeScript. SonarSource built its own proprietary JavaScript/TypeScript analyzer with its own rule set. However, SonarQube offers a sonar-eslint plugin that can import ESLint findings into SonarQube reports. This means SonarQube can display ESLint results alongside its own findings, giving teams a unified view. The SonarQube rules for JavaScript often cover similar ground to ESLint rules but are implemented independently and sometimes detect different patterns.

What is the SonarQube ESLint plugin?

The SonarQube ESLint plugin (sonar-eslint) imports ESLint analysis results into SonarQube. When configured, the plugin reads ESLint output and converts it into SonarQube issues that appear in the SonarQube dashboard alongside native SonarQube findings. This lets teams keep their existing ESLint configuration and see those results in SonarQube without duplicating rule management. It is particularly useful for teams that have invested heavily in custom ESLint rules or plugins and want those findings visible in SonarQube's centralized reporting.

Is ESLint free?

Yes, ESLint is completely free and open source under the MIT license. There is no paid edition, no premium tier, and no usage limits. The entire ecosystem - ESLint core, the flat config system, community plugins, and shared configurations - is free to use in any project, commercial or otherwise. ESLint is maintained by the OpenJS Foundation and funded through sponsorships and donations. This is one of ESLint's strongest advantages - there is zero cost regardless of team size, codebase size, or usage volume.

Is SonarQube free for JavaScript projects?

Partially. The SonarQube Community Build is free and open source for self-hosted deployment, and it includes JavaScript and TypeScript analysis with quality gates. SonarQube Cloud Free supports up to 50,000 lines of code with branch and PR analysis at no cost. For small JavaScript projects, these free tiers are genuinely useful. However, the Community Build lacks branch analysis and PR decoration, which limits its usefulness for PR-based workflows. Paid editions start at EUR 30/month for Cloud Team or approximately $2,500/year for the self-hosted Developer Edition.

Can ESLint detect security vulnerabilities?

ESLint can detect some security issues through plugins like eslint-plugin-security and eslint-plugin-no-unsanitized, but it is not a security scanner. These plugins catch common patterns like use of eval(), innerHTML assignments, and SQL string concatenation, but they do not perform taint analysis - tracking the flow of user input through your application to detect injection vulnerabilities across multiple files. SonarQube's Developer Edition and above include taint analysis for JavaScript and TypeScript, catching security issues that ESLint fundamentally cannot detect. For serious security scanning, teams pair ESLint with a dedicated SAST tool like SonarQube, Semgrep, or Snyk Code.

What is the best ESLint alternative for JavaScript linting?

The closest ESLint alternative for JavaScript linting is Biome (formerly Rome), which combines linting and formatting in a single Rust-based tool that runs significantly faster than ESLint. Biome supports JavaScript, TypeScript, JSX, and JSON with built-in formatting that replaces Prettier. However, Biome's rule set is smaller than ESLint's ecosystem of plugins, and community adoption is still growing. Other alternatives include deno lint for Deno projects and oxlint, a Rust-based linter focused on catching bugs. For most teams, ESLint remains the standard due to its massive plugin ecosystem and universal adoption.

How do I configure SonarQube to work with ESLint?

To use SonarQube alongside ESLint, configure your CI/CD pipeline to run both tools. ESLint runs through your build process or pre-commit hooks using your .eslintrc or eslint.config.js configuration. SonarQube analysis runs via the SonarScanner, which you add as a CI step after your build. To import ESLint results into SonarQube, install the sonar-eslint plugin and configure it to read ESLint's JSON output. Alternatively, you can run them independently - ESLint for editor and pre-commit feedback, SonarQube for CI-level analysis. Most teams do not need the import plugin and simply run both tools separately.

Does SonarQube support ESLint flat config?

SonarQube's own JavaScript analyzer does not read or use ESLint configuration files (neither the legacy .eslintrc format nor the new flat config format in eslint.config.js). SonarQube maintains its own rule configuration through Quality Profiles in the SonarQube dashboard. If you use the sonar-eslint import plugin, it reads the output of ESLint (not the config files), so it works regardless of whether you use flat config or the legacy format. Your ESLint configuration remains independent of SonarQube's configuration.

Which catches more JavaScript bugs - SonarQube or ESLint?

SonarQube catches more JavaScript bugs overall because its analysis engine performs deeper inspection including cross-file data flow analysis and taint tracking that ESLint cannot do. SonarQube's JavaScript/TypeScript rule set includes rules for resource management, complex control flow issues, and security vulnerabilities that require understanding code across multiple files. However, ESLint catches certain code style and convention issues that SonarQube considers low priority and may not flag. The two tools have overlapping but not identical coverage, which is why using both provides the most comprehensive bug detection.

Should I use Prettier with ESLint and SonarQube?

Yes, Prettier handles code formatting (semicolons, quotes, indentation, line width), ESLint handles code quality and potential bugs, and SonarQube handles deep analysis, security scanning, and quality gate enforcement. This three-tool combination is standard in professional JavaScript and TypeScript teams. Configure Prettier to run first (formatting), then ESLint (linting), then SonarQube (deep analysis in CI). Use eslint-config-prettier to disable ESLint formatting rules that conflict with Prettier. SonarQube does not conflict with either tool since it runs independently in the CI pipeline.

Explore More

Tool Reviews

Free Newsletter

Stay ahead with AI dev tools

Weekly insights on AI code review, static analysis, and developer productivity. No spam, unsubscribe anytime.

Join developers getting weekly AI tool insights.

Related Articles