Configuring ESLint to give Copilot the right feedback signals

Published 2026-01-28 by Owner

GitHub Copilot’s chat panel reads diagnostics from the active editor. When ESLint flags an issue in real time, Copilot can see it in the next interaction. Configured well, ESLint becomes a real-time feedback loop that shapes Copilot’s suggestions toward your project’s conventions.

The trick is configuring ESLint to flag the things you actually care about, not flooding the diagnostics panel with style noise.

The signal-to-noise problem

A typical ESLint config has 50+ rules enabled by default (especially with @typescript-eslint and other plugin sets). Many flag things that:

Auto-fix on save (no need to surface to the model)
Are stylistic preferences (low impact on AI suggestions)
Are duplicates of TypeScript errors (the type checker already covers them)

When all of these flood the diagnostics panel, Copilot’s chat panel includes them in its context, but the signal that matters is buried in noise.

What rules give the model useful signals

The categories where ESLint catches things that genuinely improve AI suggestions:

Async correctness. Floating promises, missed awaits, returning promises from non-async functions. These are real bugs the model can fix when flagged.

'@typescript-eslint/no-floating-promises': 'error',
'@typescript-eslint/no-misused-promises': 'error',

Exhaustiveness checks. Unhandled cases in discriminated unions, missing default in switch, missing branches.

'@typescript-eslint/switch-exhaustiveness-check': 'error',

Strict boolean expressions. Forces explicit truthiness checks rather than relying on JavaScript coercion.

'@typescript-eslint/strict-boolean-expressions': 'warn',

No unsafe assignment / call. Catches code that “any-leaks” through the type system.

'@typescript-eslint/no-unsafe-assignment': 'error',
'@typescript-eslint/no-unsafe-call': 'error',
'@typescript-eslint/no-unsafe-member-access': 'error',

Consistent type imports. Preserves type-only imports for build optimization.

'@typescript-eslint/consistent-type-imports': 'error',

These rules surface real issues. When Copilot sees them, suggestions account for them.

What rules to disable for AI signal

Some rules generate noise that doesn’t help the AI:

Style rules with auto-fix. prefer-const, no-var, indent rules. Your formatter handles these; surfacing them to Copilot is noise.

Naming conventions. naming-convention rule sets are project-specific and the violations are usually unimportant for AI work. Disable or scope tightly.

Many of @typescript-eslint/recommended’s defaults. Some are noisy. Audit which actually catch real issues in your codebase vs. which are persistent low-priority noise.

'@typescript-eslint/no-unused-vars': 'off', // tsc handles this
'no-console': 'off', // contextual; not always wrong
'@typescript-eslint/no-explicit-any': 'warn', // sometimes any is correct

The principle: if your team would auto-fix it and never discuss it, the AI doesn’t need to see it either.

Config patterns that work

For a typical TypeScript project:

// eslint.config.js
import tseslint from 'typescript-eslint';

export default tseslint.config({
  files: ['**/*.{ts,tsx}'],
  extends: [...tseslint.configs.recommendedTypeChecked],
  rules: {
    // High-signal rules: keep on
    '@typescript-eslint/no-floating-promises': 'error',
    '@typescript-eslint/no-misused-promises': 'error',
    '@typescript-eslint/switch-exhaustiveness-check': 'error',
    '@typescript-eslint/no-unsafe-assignment': 'error',
    '@typescript-eslint/no-unsafe-call': 'error',
    '@typescript-eslint/no-unsafe-member-access': 'error',
    '@typescript-eslint/consistent-type-imports': 'error',
    '@typescript-eslint/strict-boolean-expressions': 'warn',
    
    // Disabled to reduce noise
    '@typescript-eslint/no-explicit-any': 'warn',
    '@typescript-eslint/no-unused-vars': 'off',
    'no-console': 'off',
  },
});

This is intentionally minimal. The goal is “every flagged diagnostic represents something the AI should fix” rather than “every possible style issue is captured.”

Project-specific rules

A few rules that depend on your project but are worth considering:

For Next.js apps:

'@next/next/no-html-link-for-pages': 'error',
'@next/next/no-img-element': 'error',

These catch Next.js-specific patterns. Copilot’s defaults sometimes use plain <a> and <img> instead of Next’s <Link> and <Image>. ESLint flags it; Copilot self-corrects.

For React:

'react-hooks/exhaustive-deps': 'error',
'react-hooks/rules-of-hooks': 'error',

These are essential. Copilot occasionally writes hook code that violates the rules of hooks. ESLint catches it.

For Node:

'n/no-missing-import': 'error',
'n/no-unsupported-features/es-syntax': 'off', // we use bundlers

The first catches imports that won’t resolve. Useful when Copilot suggests imports of packages you don’t have.

What this gets you

After tuning ESLint to give Copilot good signals, the experience changes in specific ways:

First-attempt suggestions get better. Copilot’s defaults are tweaked by the rule set it sees.

Iteration is faster. When a suggestion has an issue, ESLint flags it, and Copilot fixes it on the next turn. The loop closes faster than asking Copilot to “review and fix” generically.

Code quality stays consistent. Things that should be fixed get fixed; things that don’t matter don’t get attention.

The investment is real but bounded — a few hours to audit your ESLint config and decide what to keep. The payoff is ongoing better AI assistance.

Per-language considerations

The principles transfer to other languages:

Python: ruff with high-signal rules (no shadowing, no bare except, async/await issues). Same pattern: enable rules that catch real bugs, disable style noise.

Go: golangci-lint with rules like errcheck, ineffassign, gosec. The Go equivalent of “useful diagnostics that the AI can act on.”

Rust: clippy with the default plus a few extra lints (e.g., dbg! usage, unwrap_used for production code). Clippy is opinionated but configurable.

For each language, the principle is the same: tune the linter to surface real issues that benefit from AI attention. Disable noise that doesn’t help.

A measurement

Across a project I tuned this for, the comparison:

Before tuning (default ESLint config):

~12 diagnostics per file on average
Most were stylistic
Copilot’s suggestions ignored most of the noise

After tuning:

~2 diagnostics per file on average
Each represents a real issue
Copilot’s suggestions actively address the diagnostics

The reduction in noise let me see what mattered. It also let Copilot focus on what mattered.

A note on TypeScript strict mode

ESLint diagnostics complement TypeScript strict mode. With strict mode on:

Type errors fire in real-time
Copilot sees the type errors in the chat panel
Suggestions account for the type system

This is the strongest possible feedback for Copilot. Type system + linter together catch most categories of mistakes the model would make.

If your project doesn’t have strict mode on, enabling it (gradually, with // @ts-expect-error for the legacy issues) is a higher-leverage change than ESLint tuning. Strict mode is the bigger lever.

Closing observation

The diagnostics surface is the AI’s window into your project’s conventions. Treat it deliberately. A noisy diagnostics panel is wasted; a focused one is a real-time feedback loop that improves AI behavior.

This applies regardless of which AI tool you use. Cursor, Copilot, Cline — all use diagnostics as context. The investment in good linting pays off across all of them.