Come Configurare ESLint e Prettier in VS Code per Progetti JavaScript

by

Se hai provato ad attivare ESLint e Prettier in VS Code su un progetto JavaScript e ti sei ritrovato con virgolette che cambiano a ogni salvataggio, punti e virgola che compaiono e scompaiono o l’editor che riformatta il codice due volte in modo diverso, sei nel posto giusto. Il problema non sono gli strumenti: è il modo in cui vengono fatti convivere.

In questa guida configuriamo da zero ESLint (qualità del codice) e Prettier (formattazione) dentro Visual Studio Code, con file di configurazione commentati riga per riga, formattazione automatica al salvataggio e set di regole pronti per React e Node.js. Alla fine trovi una tabella con i conflitti più comuni e la relativa soluzione, più una FAQ.

ESLint vs Prettier: chi fa cosa (e perché litigano)

La regola d’oro, indicata anche dalla documentazione ufficiale di Prettier, è semplice: Prettier si occupa della formattazione, ESLint della qualità del codice. Il conflitto nasce quando ESLint contiene anche regole stilistiche (indentazione, virgolette, punto e virgola) che si sovrappongono a quelle di Prettier.

Aspetto ESLint Prettier
Scopo principale Trovare bug, anti-pattern, variabili inutilizzate, hook usati male Riscrivere il codice con uno stile uniforme
Configurabilità Molto alta, centinaia di regole e plugin Volutamente ridotta, poche opzioni
Output tipico Warning ed errori nel Problems panel File riformattato al salvataggio
Ruolo consigliato Linter, senza regole di stile Unico formatter del progetto

La strategia vincente: lasciare a Prettier il monopolio della formattazione e disattivare in ESLint tutte le regole stilistiche tramite il pacchetto eslint-config-prettier. Niente doppioni, niente conflitti.

code editor screen

Prerequisiti

  • Node.js in versione LTS attiva installata (verifica con node -v)
  • Un progetto con package.json (se non ce l’hai: npm init -y)
  • Visual Studio Code aggiornato
  • ESLint 9 o superiore, che usa il formato flat config (eslint.config.js) al posto del vecchio .eslintrc

Step 1: installare le due estensioni giuste in VS Code

Apri il pannello Extensions (Ctrl+Shift+X oppure Cmd+Shift+X su Mac) e installa solo queste due:

  1. ESLint di Microsoft, identificativo dbaeumer.vscode-eslint
  2. Prettier – Code formatter, identificativo esbenp.prettier-vscode

Puoi installarle anche da terminale:

code --install-extension dbaeumer.vscode-eslint
code --install-extension esbenp.prettier-vscode

Attenzione alle estensioni doppione

Molti sviluppatori installano anche Prettier ESLint (rvest.vs-code-prettier-eslint) o vecchi formatter JavaScript: è la causa numero uno del codice che viene formattato due volte in modo diverso. Tieni installata una sola estensione di formattazione. Se hai dubbi, disabilita le altre a livello di workspace.

code editor screen

Step 2: installare i pacchetti npm nel progetto

Le estensioni di VS Code non bastano: ESLint e Prettier devono vivere nel progetto, così tutto il team (e la CI) usa le stesse regole.

Progetto Node.js puro

npm i -D eslint @eslint/js globals prettier eslint-config-prettier

Progetto React

npm i -D eslint @eslint/js globals prettier eslint-config-prettier eslint-plugin-react eslint-plugin-react-hooks

Il pacchetto chiave è eslint-config-prettier: non aggiunge regole, ne spegne una lunga lista, ovvero tutte quelle che entrerebbero in conflitto con Prettier.

Step 3: il file eslint.config.js commentato

Crea il file eslint.config.js nella root del progetto. Con la flat config l’ordine conta: la configurazione di Prettier va sempre per ultima, perché deve sovrascrivere e disattivare le regole precedenti.

Configurazione per Node.js

import js from "@eslint/js";
import globals from "globals";
import prettier from "eslint-config-prettier/flat";

export default [
  // 1. File e cartelle da ignorare completamente
  {
    ignores: ["node_modules/**", "dist/**", "build/**", "coverage/**"]
  },

  // 2. Regole base raccomandate da ESLint
  js.configs.recommended,

  // 3. Impostazioni del linguaggio e regole personalizzate
  {
    files: ["**/*.js", "**/*.mjs", "**/*.cjs"],
    languageOptions: {
      ecmaVersion: "latest",
      sourceType: "module",
      globals: {
        ...globals.node // riconosce process, __dirname, Buffer ecc.
      }
    },
    rules: {
      // Segnala le variabili non usate, ma ignora gli argomenti che iniziano con _
      "no-unused-vars": ["warn", { argsIgnorePattern: "^_" }],
      // In produzione i console.log sporcano i log del server
      "no-console": ["warn", { allow: ["warn", "error"] }],
      // Vieta le variabili non dichiarate
      "no-undef": "error",
      // Preferisci const quando la variabile non viene riassegnata
      "prefer-const": "error",
      // Evita await dentro i cicli, tipico collo di bottiglia in Node
      "no-await-in-loop": "warn"
    }
  },

  // 4. SEMPRE PER ULTIMO: disattiva ogni regola stilistica in conflitto con Prettier
  prettier
];

Nota: se usi una versione di eslint-config-prettier precedente alla 10, l’import corretto è import prettier from "eslint-config-prettier"; senza il suffisso /flat.

Configurazione per React

import js from "@eslint/js";
import globals from "globals";
import react from "eslint-plugin-react";
import reactHooks from "eslint-plugin-react-hooks";
import prettier from "eslint-config-prettier/flat";

export default [
  { ignores: ["node_modules/**", "dist/**", "build/**"] },

  js.configs.recommended,

  {
    files: ["**/*.{js,jsx}"],
    languageOptions: {
      ecmaVersion: "latest",
      sourceType: "module",
      globals: {
        ...globals.browser // window, document, fetch...
      },
      parserOptions: {
        ecmaFeatures: { jsx: true } // abilita la sintassi JSX
      }
    },
    settings: {
      react: { version: "detect" } // legge la versione di React dal package.json
    },
    plugins: {
      react,
      "react-hooks": reactHooks
    },
    rules: {
      ...react.configs.flat.recommended.rules,
      ...reactHooks.configs.recommended.rules,

      // Con React 17+ non serve importare React in ogni file
      "react/react-in-jsx-scope": "off",
      // Se non usi PropTypes (progetti moderni o TypeScript) disattivala
      "react/prop-types": "off",
      // Errore bloccante: array di dipendenze degli hook incompleto
      "react-hooks/exhaustive-deps": "warn",
      "no-unused-vars": ["warn", { argsIgnorePattern: "^_" }]
    }
  },

  // Deve restare l'ultimo elemento dell'array
  prettier
];

Verifica subito che tutto giri:

npx eslint .

Step 4: il file .prettierrc e .prettierignore

Crea .prettierrc nella root. Prettier ha poche opzioni di proposito: definiscile una volta e non tornarci più.

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 90,
  "tabWidth": 2,
  "useTabs": false,
  "arrowParens": "always",
  "bracketSpacing": true,
  "endOfLine": "lf"
}
Opzione Cosa fa
semi Aggiunge il punto e virgola a fine istruzione
singleQuote Apici singoli al posto delle virgolette doppie
trailingComma Virgola finale: rende i diff Git molto più puliti
printWidth Lunghezza massima indicativa della riga
endOfLine Evita i conflitti CRLF/LF tra Windows e macOS

Poi crea .prettierignore:

node_modules
dist
build
coverage
package-lock.json
.next
*.min.js
code editor screen

Step 5: formattazione automatica al salvataggio in VS Code

Questo è il passaggio che fa la differenza. Crea la cartella .vscode nella root del progetto e dentro il file settings.json: in questo modo la configurazione viaggia con il repository e vale per tutto il team.

{
  // Prettier è l'unico formatter autorizzato
  "editor.defaultFormatter": "esbenp.prettier-vscode",

  // Formatta a ogni salvataggio
  "editor.formatOnSave": true,

  // Dopo la formattazione, ESLint applica le sue correzioni automatiche
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },

  // Formatter esplicito per linguaggio: evita sorprese
  "[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[javascriptreact]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[typescriptreact]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[json]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
  "[css]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },

  // Usa sempre la versione di Prettier installata nel progetto
  "prettier.requireConfig": true,

  // Lingue su cui ESLint deve intervenire
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ]
}

Riavvia VS Code (oppure Ctrl+Shift+P > Developer: Reload Window), apri un file JavaScript disordinato e salva. Dovresti vedere il file riformattato e gli errori ESLint auto-correggibili sistemati, in questo ordine. Using Prettier and ESLint for JavaScript formatting tratta il tema più a fondo.

Perché “explicit” e non “true”

Nelle versioni recenti di VS Code i valori booleani in editor.codeActionsOnSave sono deprecati. I valori corretti sono "explicit" (agisce solo al salvataggio manuale), "always" e "never". Se hai copiato una guida vecchia con "source.fixAll.eslint": true, aggiornala.

I conflitti tipici tra ESLint e Prettier e come risolverli

Sintomo Causa Soluzione
Il codice cambia stile a ogni salvataggio, avanti e indietro ESLint e Prettier hanno regole opposte su virgolette o indentazione Aggiungi eslint-config-prettier come ultimo elemento della flat config
Il file viene formattato due volte in modo diverso Più estensioni formatter installate Disinstalla i formatter extra e imposta editor.defaultFormatter per ogni linguaggio
Al salvataggio non succede nulla formatOnSave disattivato o prettier.requireConfig attivo senza file di config Verifica .prettierrc nella root e controlla l’output panel di Prettier
ESLint non trova la configurazione Vecchio .eslintrc.json con ESLint 9+ Migra a eslint.config.js, oppure lancia npx @eslint/migrate-config .eslintrc.json
Errore Cannot use import statement outside a module Flat config in ESM senza dichiarazione Aggiungi "type": "module" al package.json o rinomina in eslint.config.mjs
Funziona in VS Code ma non in CI Configurazione solo nelle User Settings globali Committa .vscode/settings.json, i file di config e aggiungi gli script npm
Monorepo: ESLint ignora i sottopacchetti Working directory sbagliata Imposta "eslint.workingDirectories": [{ "mode": "auto" }]

eslint-plugin-prettier: conviene usarlo?

Esiste un secondo approccio: far girare Prettier dentro ESLint con eslint-plugin-prettier, così ogni differenza di formattazione diventa un errore di lint. La stessa logica si ritrova da uno studio che prende sul serio la cosa.

  • Pro: un solo comando per lint e formattazione, utile nelle pipeline CI molto semplici.
  • Contro: più lento, il pannello Problems si riempie di errori rossi puramente estetici e il feedback nell’editor diventa rumoroso.

Consiglio pratico: per la maggior parte dei progetti React e Node.js resta sulla separazione netta (Prettier come formatter, ESLint come linter con eslint-config-prettier). È l’approccio raccomandato anche dalla documentazione ufficiale di Prettier.

code editor screen

Script npm e controllo pre-commit

La configurazione dell’editor non basta: chi apre il progetto senza VS Code deve comunque rispettare le regole. Aggiungi al package.json:

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

Per bloccare il codice non conforme prima del commit, usa husky e lint-staged:

npm i -D husky lint-staged
npx husky init
echo "npx lint-staged" > .husky/pre-commit

Poi nel package.json:

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.{json,css,scss,md}": ["prettier --write"]
  }
}

In questo modo solo i file modificati vengono controllati, e il commit fallisce se restano errori non correggibili automaticamente.

Checklist finale

  1. Estensioni dbaeumer.vscode-eslint e esbenp.prettier-vscode installate, nessun altro formatter attivo
  2. Pacchetti npm installati come devDependencies, non globalmente
  3. eslint.config.js presente, con eslint-config-prettier come ultimo elemento
  4. .prettierrc e .prettierignore nella root
  5. .vscode/settings.json versionato con formatOnSave e source.fixAll.eslint
  6. Script lint e format:check eseguiti anche in CI
  7. Hook pre-commit attivo con lint-staged

Con questi sette punti, ESLint e Prettier in VS Code smettono di essere una fonte di frustrazione e diventano quello che devono essere: un automatismo invisibile che ti fa risparmiare tempo a ogni salvataggio. Chi vuole approfondire legga VS Code Prettier ESLint.

FAQ

Qual è la differenza tra ESLint e Prettier?

ESLint è un linter: analizza il codice e segnala potenziali bug, variabili inutilizzate, hook React usati in modo scorretto e violazioni delle convenzioni. Prettier è un formatter: riscrive il codice applicando uno stile uniforme (indentazione, virgolette, a capo). Non sono alternativi, si usano insieme.

Posso usare solo Prettier senza ESLint?

Sì, ma perderesti tutta la parte di analisi statica. Prettier non ti dirà mai che hai dimenticato una dipendenza in useEffect o che stai usando una variabile mai dichiarata. Su progetti professionali servono entrambi. Il team di namastedev.com arriva a una conclusione simile.

ESLint è obsoleto nel 2026?

No. ESLint resta lo standard di riferimento per il linting JavaScript e TypeScript. Sono cambiati il formato di configurazione (flat config in eslint.config.js) e alcune regole stilistiche, oggi delegate a Prettier o a plugin dedicati. Esistono alternative più veloci scritte in Rust, ma l’ecosistema di plugin di ESLint è ancora imbattibile.

Come faccio a far girare ESLint dal terminale di VS Code?

Apri il terminale integrato con Ctrl+ù (o Ctrl+`) e lancia npx eslint . per il controllo, oppure npx eslint . --fix per applicare le correzioni automatiche a tutto il progetto.

Devo committare la cartella .vscode?

Sì, almeno il file settings.json e opzionalmente extensions.json con le estensioni consigliate. Serve a garantire che tutto il team lavori con la stessa configurazione, evitando diff Git pieni di modifiche solo formali.

Come converto un vecchio file .eslintrc in flat config?

Esegui npx @eslint/migrate-config .eslintrc.json: viene generato un eslint.config.mjs equivalente, che poi conviene ripulire a mano rimuovendo le regole stilistiche ormai gestite da Prettier.

Funziona anche con TypeScript?

Sì. Basta aggiungere typescript-eslint ai devDependencies, includere le sue configurazioni raccomandate nella flat config e mantenere eslint-config-prettier come ultimo elemento dell’array. Le impostazioni di VS Code viste sopra coprono già typescript e typescriptreact.

Leave a Comment