How to Lint JavaScript Code: A Practical Setup Guide

You pushed a fix to production. Ten minutes later, a bug report comes in: a variable referenced before it was defined.

Your test suite didn't catch it, your code review didn't catch it, and a linter would have flagged it the moment you typed it. Knowing how to lint JavaScript code isn't optional anymore. It's the fastest, cheapest quality check in your entire workflow, and most developers either skip it entirely or set it up badly and forget about it.

This guide walks through the full process: what linting actually does, how to set it up with ESLint, how to configure rules that fit your project, and how to make linting part of every stage of your workflow from your editor to your CI pipeline. If you want to check a piece of code right now without any local setup, there's a faster path covered below too.

What Is JavaScript Linting (and Why Most Devs Skip It)

Linting is static analysis. Rather than executing your code, the linter reads it and checks it against a defined set of rules. There's no runtime, no test environment, and no user actions required.

Most developers skip it for one of two reasons. Either it feels like overhead during setup, or they tried it once, got flooded with warnings, and turned it off. Both are fixable problems, and this guide addresses them directly.

The Difference Between Linting and Validation

Validation checks whether your code is syntactically correct, specifically whether the JavaScript engine can parse it at all. Linting goes further by checking code quality, style consistency, and adherence to best practices. A file can pass validation and still be full of unused variables, unreachable code, and type coercion traps that will surface as bugs later. As the team at jsontotable.org explains, linting targets the kinds of issues that don't break your code today but quietly introduce problems down the line.

What a Linter Actually Catches

A JavaScript linter flags missing semicolons, inconsistent indentation, unused variables, undefined references, and deprecated features. Beyond syntax, it catches violations of your team's coding standards, the kinds of issues that no compiler or automated test will ever surface. According to the LogRocket engineering blog, because JavaScript is dynamically typed and client-side error logs are historically hard to collect, static analysis tools deliver more value in JS than in most statically typed languages. The linter is your first line of defense, not your last.

How to Lint JavaScript Code with ESLint

ESLint is the dominant choice for JavaScript linting. It pulls over 126 million npm downloads per week and is used by engineering teams at Microsoft, Airbnb, Netflix, and Meta. If a team is linting JavaScript at any kind of scale, they're almost certainly using ESLint.

Installing ESLint in Your Project

You'll need Node.js installed at version 20.19.0, 22.13.0, or 24 and above. From your project root, run the following command:

npm init @eslint/config@latest

This command walks you through a short setup wizard that asks where your code runs, what module system you use, and whether you want the recommended ruleset out of the box. It installs ESLint and generates an eslint.config.js file automatically. When installing manually, use the --save-dev flag so that ESLint is saved as a development-only dependency, since it has no role in your production build.

Running Your First Lint Check

Once installed, you can lint a single file by running the following:

npx eslint yourfile.js

To lint your entire source directory, use this instead:

npx eslint src/

ESLint outputs a list of issues, each with a file path, line number, column, severity level, and the rule that was violated. The output is terse and direct, which is exactly what you need when working through a list of problems.

Understanding Errors vs. Warnings

ESLint uses three severity levels: error, warn, and off. An error fails the lint check and, if linting is running in CI, it fails the build. A warn surfaces the issue without blocking anything. Use errors for conventions your team considers non-negotiable and warnings for stylistic preferences or rules you're phasing in gradually. This distinction matters most when adding ESLint to an existing codebase, because setting everything to error on day one will produce a list so long that nobody acts on it.

Configuring ESLint Rules for Your Project

The default install gives you a working setup. What makes it yours is the configuration layer built on top of it.

Using the Recommended Ruleset as a Starting Point

The eslint:recommended config turns on a curated set of rules designed to catch the most common and impactful JavaScript problems, including no-unused-vars, no-undef, and no-constant-condition. It's the right place to start because you get meaningful signal without noise, and you can always tighten or relax individual rules from there.

For modern projects, ESLint's flat config format uses a single eslint.config.js file and has replaced the older .eslintrc chain. It gives you direct control over which rules apply to which file patterns, without the confusion of cascading configuration merges. If you're starting a new project, use flat config from the beginning. If you're migrating an existing one, ESLint's official migration guide walks through the process step by step.

Customizing Rules for Your Team's Standards

Rules are added under the rules key in your config file. Each rule accepts a severity string ("error", "warn", or "off") along with any optional options. For example, if your team requires semicolons, the rule looks like this:

rules: {
  semi: "error"
}

Syncfusion's comparison of JavaScript linting tools shows clearly how ESLint and Prettier serve different purposes. ESLint flags logical and structural problems while Prettier handles visual formatting, and using both together is common practice. Because they target different concerns, they don't overlap when configured correctly.

What Is the Fastest Way to Lint JavaScript Without a Setup?

Not every situation calls for a full local ESLint installation. Sometimes you have a single file, a snippet from a code review, or a script you inherited and need to audit quickly before touching your environment.

When to Use an Online JavaScript Linter

An online linter is the right tool when you don't want to touch your local environment, when you're reviewing someone else's code, or when you want a fast read on a script before integrating it. There's no install, no config file, and no Node version to manage. You paste the code and get results. This approach is also a practical starting point for developers who haven't used linting before, because seeing the feedback directly helps you understand what the rules mean and whether building it into your project is worth the setup time.

How DataHen's JS Linter Tool Works

DataHen's free JavaScript linter runs ESLint-style analysis directly in the browser. Paste your script or upload a .js file, and the tool returns a structured report with errors, warnings, and suggestions, each mapped to a specific line and rule. There's no registration required and no usage limits. For quick audits, particularly when you're working with JavaScript-heavy scraping workflows and need to validate a parser or extractor script before running it at scale, this approach removes the friction entirely.

How Do You Integrate Linting Into Your Development Workflow?

Linting on demand is better than not linting at all, but automating it is where it actually changes how you write code.

Linting on Save in VS Code

The ESLint extension for VS Code underlines issues inline as you type and can auto-fix rule violations every time you save a file. Setup takes about two minutes: install the extension, confirm that ESLint is installed in your project, and add "editor.codeActionsOnSave": { "source.fixAll.eslint": true } to your VS Code settings. Because the linter runs continuously rather than on demand, a large category of errors never makes it past your editor at all.

Adding Linting to Your CI/CD Pipeline

Editor linting catches problems for you individually, but CI linting enforces quality across the entire team. Adding a lint step to your pipeline, whether that's GitHub Actions, GitLab CI, or another system, means every pull request is checked automatically before it merges. A basic GitHub Actions setup looks like this:

- name: Run ESLint
  run: npx eslint src/

When the lint check fails, the merge is blocked. This is where the error versus warn distinction becomes most consequential, since warnings won't stop a merge but errors will. Teams that run linting in CI consistently catch style regressions, undefined variable references, and bad practice patterns before they ever reach the main branch.

Common JavaScript Linting Mistakes to Avoid

Getting ESLint running is straightforward. Getting it running in a way that actually improves your codebase takes a bit more thought.

Ignoring Warnings Until They Pile Up

I've seen codebases with over 400 accumulated warnings that nobody ever looked at. Because developers learn to ignore that volume of output, the linter becomes noise rather than signal. Treat warnings as a queue you're actively working through, not a backlog you'll address someday. When you introduce a new warning-level rule, fix the existing violations before moving on, because the value of linting comes from acting on the output, not just running it.

Using the Wrong Ruleset for Your Environment

A common mistake is applying browser globals to a Node.js project, or the reverse. ESLint doesn't know whether window or process should be defined unless you specify it explicitly, so when your config doesn't match your environment, you end up with false positives on globals while missing the real issues underneath them. The setup wizard handles this automatically when you initialize ESLint on a fresh project. On migrated projects, check the languageOptions.globals setting and confirm it reflects where your code actually runs. The same principle applies when debugging selector issues in scraping scripts, where mismatched context assumptions are typically the root cause of unexpected behavior.

Start Linting Before You Ship

Three things are worth taking away from this guide. Linting is a static check that runs before your code executes, so it catches problems your tests never see. ESLint with the recommended config and the flat config format is the fastest path to a working setup. And integrating linting into both your editor and your CI pipeline is what makes it habitual rather than a one-off check.

If you're working with a script you want to check right now, DataHen's free JavaScript linter gives you ESLint-style results in your browser without any local setup required. Paste your code and see exactly where it stands. For teams managing cleaning and validating data pipelines that include JavaScript-based processing steps, this is the quickest way to audit a script before it touches production data.