Slik setter du opp Prettier og ESLint sammen for mer konsekvent JavaScript-kode

I mange JavaScript- og TypeScript-prosjekter glir kodestil og kvalitet fort ut hvis teamet ikke har felles verktøy på plass. Små forskjeller i formatering, semikolon og import-rekkefølge gjør pull requests tyngre enn de trenger å være.

En kombinert bruk av Prettier og ESLint gir et klart skille mellom formatering og kodekvalitet. Resultatet er renere diffs, mindre synsing i kodegjennomganger og et prosjekt som er enklere å holde ved like.

Hvorfor kombinere Prettier og ESLint

Prettier tar seg av hvordan koden ser ut: innrykk, anførselstegn, linjelengde og lignende. ESLint fokuserer på hva koden gjør: potensielle feil, ubrukte variabler, mer lesbare mønstre og prosjektspesifikke regler.

Hvis begge verktøy prøver å styre formateringen, får du fort konflikter. Derfor er målet å la Prettier eie formatering, mens ESLint konsentrerer seg om logikk og beste praksis.

Grunnoppsett: legg verktøyene inn i prosjektet

Start med å installere avhengigheter lokalt i prosjektet, gjerne via npm:

Installer Prettier:

npm install --save-dev prettier

Installer ESLint:

npm install --save-dev eslint

Kjør deretter oppsett-veilederen til ESLint, slik at du slipper å huske alle valgene manuelt:

npx eslint --init

Konfigurasjon av Prettier: start enkelt

Opprett en fil .prettierrc i prosjektroten. Begynn med få valg, så kan du og teamet justere etter hvert:

{
"singleQuote": true,
"semi": false,
"trailingComma": "es5",
"printWidth": 100
}

Poenget er at formatteren skal være forutsigbar. Det er viktigere at alle følger samme stil enn hvilken stil dere velger.

Konfigurasjon av ESLint: skill tydelig mellom roller

Når du har kjørt eslint --init, vil du ha en konfigurasjonsfil, for eksempel .eslintrc.json. Der legger du til Prettier-integrasjonen for å unngå dupliserte regler.

Installer tilleggene som gjør at ESLint og Prettier snakker sammen:

npm install --save-dev eslint-config-prettier eslint-plugin-prettier

Slik kobler du ESLint og Prettier sammen

Oppdater .eslintrc.* slik at Prettier kjører som en del av ESLint-reglene. Et typisk oppsett for et moderne JavaScript-prosjekt kan se slik ut:

{
"env": {
"browser": true,
"es2021": true
},
"extends": [
"eslint:recommended",
"plugin:react/recommended",
"plugin:prettier/recommended"
],
"plugins": ["react", "prettier"],
"rules": {
"prettier/prettier": "error",
"no-unused-vars": ["warn", { "argsIgnorePattern": "^_" }]
}
}

Her gjør "plugin:prettier/recommended" to ting: deaktiverer ESLint-regler som krasjer med Prettier, og slår på en regel som rapporterer Prettier-avvik som ESLint-feil.

Typisk arbeidsflyt i et team

For å få mest nytte bør Prettier og ESLint inngå i hverdagsflyten, ikke bare kjøres av og til. Det kan du løse med noen faste steg i prosjektet:

• Ved lagring i editor: formater automatisk med Prettier, og kjør ESLint-visning.
• Ved commit: kjør en kort lint og auto-fix på berørte filer.
• I CI: kjør full ESLint-sjekk uten auto-fix som del av bygget.

Dette gir tidlig tilbakemelding, og du unngår at små stilbrudd sklir inn i main-branch.

Konfigurer scripts i package.json

Definer noen enkle kommandoer i package.json, så slipper alle å huske lange CLI-kall:

{
"scripts": {
"lint": "eslint src --ext .js,.jsx,.ts,.tsx",
"lint:fix": "eslint src --ext .js,.jsx,.ts,.tsx --fix",
"format": "prettier . --write"
}
}

Nå kan utviklere kjøre npm run lint før de pusher, og npm run format når de vil rydde opp i formatering i hele repoet.

Pre-commit hooks med Husky og lint-staged

For å sikre at kode som committes er sjekket, er pre-commit hooks nyttige. En vanlig kombinasjon er Husky og lint-staged.

Installer pakkene:

npm install --save-dev husky lint-staged

Aktiver Husky og legg til en pre-commit hook:

npx husky install
npx husky add .husky/pre-commit "npx lint-staged"

Lint-staged: bare endrede filer

Legg til lint-staged-oppsett i package.json slik at bare endrede filer sjekkes:

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

Resultatet er raskere hooks, og du tvinger ingen til å rydde gamle filer de ikke har tatt i.

Vanlige feil og enkle løsninger

Noen typiske irritasjonsmomenter går igjen når man kobler disse verktøyene sammen. Heldigvis har de ofte enkle forklaringer.

• Kode “hopper” ved lagring: sjekk at editoren ikke har egen formatering aktiv i tillegg til Prettier.
• ESLint og Prettier er uenig om semikolon: sørg for at ESLint ikke har stilregler som krasjer, og at du bruker eslint-config-prettier.
• CI feiler på Windows vs macOS: pass på at scripts ikke er avhengig av shell-spesifikk syntaks, og vurder å bruke cross-env ved behov.

Når bør du justere oppsettet

Oppsettet bør ikke være helt låst. Etter noen ukers bruk kan teamet vurdere om reglene treffer riktig. Får dere støy fra regler som mest skaper frustrasjon, kan de justeres eller tones ned til advarsler.

Samle gjerne opp forslag i løpet av en sprint, og gjør endringer i plenum i stedet for å diskutere formatering i hver enkelt pull request.

Sjekkliste for et robust oppsett

Her er en kort oversikt du kan bruke når du setter opp eller rydder et prosjekt:

• Prettier er installert med en enkel .prettierrc.
• ESLint er konfigurert for miljøet ditt (browser, node, React, TypeScript).
• eslint-config-prettier og eslint-plugin-prettier er aktivert.
• npm run lint og npm run format fungerer og er dokumentert for teamet.
• Pre-commit hooks kjører ESLint og Prettier på endrede filer.
• CI-pipelinen kjører ESLint som en egen jobb før bygg og deploy.

Med dette på plass slipper du mange unødvendige diskusjoner om stil, og kan bruke mer tid på funksjonalitet og arkitektur.