Disable an ESLint Rule for One Line in JavaScript

ESLint supports special directive comments that can disable rules for the next line, the current line, a block of code, or an entire file. The safest option is usually eslint-disable-next-line with the specific rule name, because it keeps the suppression narrow and visible.

ESLint reports code that violates rules configured for a project. Occasionally, code must intentionally break a rule: perhaps an external API requires a naming style, legacy code cannot yet be changed, or a safe exception is needed.

Instead of disabling linting everywhere, ESLint lets you add directive comments. A directive tells ESLint where a rule should temporarily stop reporting problems.

For a single following line, use:

// eslint-disable-next-line rule-name

For example, if ConstructorFunction is intentionally provided by a global script and ESLint reports no-undef:

// eslint-disable-next-line no-undef
$scope.someVar = ConstructorFunction();

Naming the exact rule is important. It documents the reason for the exception and prevents unrelated lint rules from being silently ignored.

Think of ESLint as a spelling and safety checker for code. A directive comment is a small, temporary permission slip.

• eslint-disable-next-line is permission for one task.
• eslint-disable is permission for a short period.
• eslint-enable ends that permission.

Give permission only where it is needed. A permission slip for one line is much safer than turning off the checker for an entire file.

Use an ESLint directive comment immediately before the code it affects.

Disable one named rule on the next line

// eslint-disable-next-line no-console
console.log("Debugging checkout flow");

Only the no-console warning for the next line is suppressed.

Disable all ESLint rules on the next line

// eslint-disable-next-line
legacyLibrary.doSomething();

This works, but it is usually better to specify a rule name. Otherwise, new problems on that line can be hidden.

Disable a rule for a small block

/* eslint-disable no-console */
console.log("Starting import");
console.log("Import complete");
/* eslint-enable no-console */

The no-console rule is disabled between the two comments and enabled again afterward.

Disable a rule on the same line

console.log("Temporary diagnostic"); // eslint-disable-line no-console

Use this when placing the directive before the line is inconvenient. The next-line form is generally easier to read.

Consider this code in a project where no-console is enabled:

function calculateTotal(price, quantity) {
  // eslint-disable-next-line no-console
  console.log({ price, quantity });

  return price * quantity;
}

1. ESLint reads the function declaration. There is no no-console issue yet.
2. ESLint reads the directive comment.
3. The comment tells ESLint not to report the no-console rule on the next line only.
4. ESLint checks console.log({ price, quantity }), but suppresses its no-console report.
5. ESLint checks the return statement normally.
6. If another console.log appears later, ESLint reports it because the directive has already expired.

function calculateTotal(price, quantity) {
  // eslint-disable-next-line no-console
  console.log({ price, quantity });

  console.log("This is still reported");
  return price * quantity;
}

• Temporary debugging: Allow one console.log while investigating a production-only issue.
• Third-party globals: Suppress no-undef for a value loaded by an older external script while the integration is being modernized.
• Framework or API constraints: Permit a required parameter name that violates a naming convention.
• Migration work: Isolate a known exception while incrementally moving legacy code to new project rules.
• Generated or compatibility code: Suppress a narrowly scoped rule when changing the generated code is not practical.

A directive should describe an intentional exception, not replace fixing ordinary code-quality problems.

In maintained codebases, developers usually follow these patterns:

Prefer a narrow, named suppression

// eslint-disable-next-line no-console -- Needed while diagnosing payment-provider responses.
console.log(providerResponse);

The rule name and reason make code review easier.

Prefer fixing configuration for known globals

If a value is genuinely global throughout an application, configure it instead of adding repeated no-undef suppressions. For example, in an ESLint flat config:

export default [
  {
    languageOptions: {
      globals: {
        ConstructorFunction: "readonly"
      }
    }
  }
];

Then code can use the global without a directive:

$scope.someVar = ConstructorFunction();

Use guard clauses instead of suppressing valid warnings

If ESLint warns about unsafe or unclear code, restructure it when possible:

function getDisplayName(user) {
  if (!user) {
    return "Guest";
  }

  return user.name;
}

Suppressions are best reserved for deliberate exceptions, not as a shortcut around a useful warning.

Putting eslint-disable-next-line after the line

This does not disable the line above it:

console.log("Debug");
// eslint-disable-next-line no-console

Place it directly before the target line:

// eslint-disable-next-line no-console
console.log("Debug");

Disabling every rule unnecessarily

// eslint-disable-next-line
console.log("Debug");

This can hide multiple unrelated problems. Prefer:

// eslint-disable-next-line no-console
console.log("Debug");

Forgetting to re-enable a block rule

/* eslint-disable no-console */
console.log("Debug");

console.log("This may be unintentionally ignored too");

Always close a block suppression as soon as possible:

/* eslint-disable no-console */
console.log("Debug");
/* eslint-enable no-console */

Suppressing no-undef instead of declaring a real global

If many files use the same external global, configure it in ESLint rather than repeating comments. Repeated suppressions make typo detection less reliable.

Using a directive to hide code that should be fixed

A lint warning often identifies a real issue. First ask whether changing the code, adding validation, or adjusting project configuration is a better solution.

For the original JSHint-style block, ESLint's closest equivalent is:

/* eslint-disable no-undef */
$scope.someVar = ConstructorFunction();
/* eslint-enable no-undef */

However, if only one line needs the exception, prefer:

// eslint-disable-next-line no-undef
$scope.someVar = ConstructorFunction();

// Disable one rule for the next line
// eslint-disable-next-line no-console
console.log("Debug");

// Disable all rules for the next line (avoid when possible)
// eslint-disable-next-line
someLegacyCall();

// Disable one rule for the current line
console.log("Debug"); // eslint-disable-line no-console

// Disable a rule for a block
/* eslint-disable no-console */
console.log("Start");
console.log("End");
/* eslint-enable no-console */

// Disable multiple rules for the next line
// eslint-disable-next-line no-console, no-alert
console.log("Debug");
alert("Done");

• Put eslint-disable-next-line immediately before the affected line.
• Name the specific rule whenever possible.
• Keep disabled blocks small.
• Add a short reason for non-obvious exceptions.
• Configure genuine project-wide globals or conventions instead of suppressing the same warning repeatedly.

How do I disable ESLint for one line?

Put // eslint-disable-next-line rule-name directly above the line. For example:

// eslint-disable-next-line no-console
console.log("Debug");

Can I disable multiple ESLint rules on one line?

Yes. Separate rule names with commas:

// eslint-disable-next-line no-console, no-alert
console.log("Debug");

What is the ESLint equivalent of jshint ignore:start and ignore:end?

Use /* eslint-disable rule-name */ before the section and /* eslint-enable rule-name */ after it.

Should I omit the ESLint rule name?

Usually no. Omitting it disables all rules in the selected scope, which can hide unrelated errors.

Why does eslint-disable-next-line not work?

Check that the comment is immediately before the target line, that the rule name is correct, and that ESLint is actually running on the file.

Should I disable no-undef for a global variable?

For a single exceptional use, a narrow directive can be acceptable. For a real application-wide global, declare it in ESLint configuration so ESLint can still catch misspellings.

Can an ESLint directive include a reason?

Yes. Add an explanatory comment after the directive, commonly using --:

// eslint-disable-next-line no-console -- Required during incident investigation.
console.log(details);

• ESLint configuration — Defines rules, environments, globals, and file-specific overrides.
• Linting rules — Explains what ESLint checks and why projects enforce code conventions.
• JSHint — Another JavaScript linter with different configuration and directive syntax.
• Global variables — Relevant when no-undef reports identifiers supplied by scripts or runtime environments.
• Code comments — Directive comments are machine-readable comments with special behavior.
• Debugging with console.log — Common reason developers temporarily suppress the no-console rule.
• Static analysis — The broader practice of examining code for issues without executing it.