Du kan næsten altid være sikker på, at et godt stykke skriftligt materiale har været genstand for en god redigering. I denne henseende er kode ikke anderledes end prosa. En af de fordele, vi nyder godt af som udviklere og programmører, er redaktører eller kodelinters, som kan indbygges i vores arbejdsgange.

Linting er den handling eller proces, hvor man kontrollerer sin kode for fejl af enhver art. Der er mange tanker om, hvordan man kan optimere effektiviteten af et givet stykke kode. Men at kontrollere, at den er fejlfri og overholder en bestemt stilguide, er grundlinjen. Nogle gange er det et spørgsmål om konsistens og læsbarhed, andre gange er det et spørgsmål om at få koden til at køre i første omgang.

Når det kommer til JavaScript linting, er der en håndfuld værktøjer, der skiller sig ud. Lad os se på fire lintere, der kan hjælpe dig med at komme i gang eller forfine din lintingproces: JSLint, standardJS, JSHint og ESLint.

JSLint

JSLint blev oprettet i 2002 af Douglas Crockford, som også skrev hvad der nok er en af de bedste bøger om JavaScript. JSLint bringer enkelhed og hastighed til bordet. Men det er også meget holdningspræget, hvilket kan være en velsignelse eller en forbandelse.

JSLint består af et enkelt sidesite, som er domineret af et tekstfelt, hvor du kan indsætte din kode. Klik på knappen “JSLint”, og eventuelle fejl, stilistiske, syntaktiske eller andre fejl, vil blive vist under tekstfeltet. Under tekstfeltet er der en lille liste af muligheder, der kan konfigureres ved hjælp af afkrydsningsfelter. Valgmulighederne omfatter tolerance af ekstra whitespace, brug af nøgleordet ‘this’ (som Crockford fraråder i sine foredrag) og inddragelse af Node.js.

Hvis du ikke er bundet af en bestemt stilguide, og du ønsker en pålidelig kilde til at kontrollere din kode for dig, er JSLint en god mulighed. Det er især effektivt til test af kodestumper, eller hvis du leder efter en måde til hurtigt at linte små projekter – måske et statisk websted med en enkelt side, der kun indeholder en enkelt JavaScript-fil.

standardJS

Baseret udelukkende på GitHub-stjerner er standardJS den mest populære løsning, der kommer ind på næsten 19.000 stjerner. Den er fuldstændig meningsbestemt, hvilket betyder, at den ikke kan tilpasses overhovedet. Men hvis du ikke er bundet til en bestemt stilguide, kan det være en velsignelse. Den kommer i form af en Node CLI og kan installeres globalt eller som en udviklingsafhængighed ved hjælp af din terminal eller valgfri kommandolinje:

$ npm install standard --global// or$ npm install standard --save-dev

Da standardJS har Node og npm som forudsætninger, og da den køres fra kommandolinjen eller ved hjælp af et npm-script, er baren hævet en smule fra JSLints niveau. Men fordi det ikke kan konfigureres, har du ikke meget andet at bekymre dig om. Du kan køre den fra kommandolinjen som en kommando med ét ord, og den vil kontrollere alle filer med en .js-udvidelse i din aktuelle arbejdskatalog.

Alle fejl, den finder, vil blive udskrevet til din terminal eller kommandolinje. Du kan forvente at se output svarende til dette eksempel fra standardJS-dokumentationen:

$ standardError: Use JavaScript Standard Stylelib/torrent.js:950:11: Expected '===' and instead saw '=='.

Hvis du skal angive en fil eller en mappe, kan du medtage stien som et argument og bruge jokertegn. Den accepterer også jokertegn. I dette eksempel vil standardJS søge efter og lint alle JavaScript-filer i mappen src og dens undermapper:

$ standard "src/**/*.js" --fix

Flaget --fix efter filstien er indstillingen til automatisk at rette fejl, efterhånden som de bliver fundet. Dette kan være en stor tidsbesparelse, men det kan også være en god læringsøvelse at rette fejlene selv.

Hvis du vil udforske de konventioner og regler, som standardJS bruger, før du beslutter dig for, om du vil bruge det, kan du finde en komplet liste her. StandardJS er en god mulighed for dig, der leder efter en hurtig og pålidelig måde at komme i gang med en JavaScript-linter.

JSHint

JSHint begyndte som en fork af JSLint. Målet var at lave en mere konfigurerbar linter. Hvis du har brugt standardJS, eller en anden meningsskabende linter, og du leder efter en måde at begynde at tilpasse dine egne lintingregler på, er JSHint måske noget for dig. Den har de fleste af fordelene ved de førnævnte lintere og lidt til.

Lige JSLint har JSHint-hjemmesiden et tekstfelt, hvor du kan indsætte kode. Metrics-feltet til højre for tekstfeltet opdateres i realtid, efterhånden som du skriver, og der udarbejdes en løbende liste over statistik om din kode, f.eks. en optælling af, hvor mange funktioner den indeholder. Selvfølgelig vises også eventuelle lintingfejl, som den finder.

Hvis du ikke bryder dig om copy/paste-metoden, og du vil bage den ind i dit projekt, kan JSHint installeres globalt eller som en projektafhængighed ved hjælp af npm:

$ npm install jshint --global// or$ npm install jshint --save-dev

Når den er installeret, bruger du CLI’en til at lint’e din kode. Her er to eksempelkommandoer, der kontrollerer henholdsvis en enkelt fil og en mappe:

$ jshint index.js// or$ jshint src/

I det første eksempel vil JSHint lint’e filen index.js, og i det andet vil den rekursivt søge i mappen ‘src/’ og lint’e alle JavaScript-filer, den finder. JSHint udskriver alle de fejl, den finder, i din terminal.

Hvis du er ligeglad med tilpasninger, kan JSHint bruges som beskrevet i ovenstående eksempler, og det vil fungere fint. Men herfra kan kompleksiteten stige betydeligt, fordi JSHint kan konfigureres fuldstændigt, og det udsætter også et API, hvilket betyder, at det kan bruges som et JavaScript-modul i dine egne JavaScript-filer.

En brugerdefineret konfiguration, som skal gemmes i en fil med navnet .jshintrc, filen kan se således ud:

{"esversion": 5,"eqeqeq": true,"strict": true}

Dette eksempel sætter fra top til bund ECMAScript-versionen til 5, kræver brug af tre lighedstegn ( === eller !==) i stedet for to (== eller !=), når værdier sammenlignes, og håndhæver strict mode. Du kan inkludere dine brugerdefinerede konfigurationer ved at angive stien til din .jshintrc-fil bag et -- config-flag på kommandolinjen eller ved at deklarere dem som attributten “jshintConfig” i din package.json-fil i dit projekt. JSHint vil bruge sine standardindstillinger for alle regler, du ikke tilpasser.

Kommandolinjeindstillingen kan se således ud:

// looks for '.jshintrc' in the current directory$ jshint --config './.jshintrc'

Mens package.json-indstillingen kan se således ud:

{ "jshintConfig": { "esversion": 5, "eqeqeq": true, "strict": true }}

Du kan bruge disse grundlæggende oplysninger til at komme i gang med at tilpasse dine egne lintingregler med JSHint. Hvis du er på udkig efter mere, indeholder den officielle dokumentation en udtømmende beskrivelse af, hvordan du bruger JSHint API’et og alle de måder, hvorpå det kan tilpasses til dine behov.

ESLint

GitHub-stjerner til side, når det kommer til JavaScript-linting, er ESLint sandsynligvis den linter, der ses mest i naturen, og den vil være den foretrukne for mange mennesker. I sin egen dokumentation sammenligner den sig selv med JSLint og JSHint med hensyn til de metoder, den bruger til parsing af JavaScript. Og i lighed med JSHint kan du lette indførelsen ved at bruge standardindstillinger og tilføje tilpasninger, efterhånden som dine præferencer eller behov ændrer sig.

For at komme i gang med ESLint skal du installere den globalt eller som en udviklingsafhængighed:

$ npm install eslint --save-dev// or$ npm install eslint --global

Hvis du installerer ESLint globalt, vil dens konfigurationer gælde for alle projektfiler, som du kører den imod. Men hvis du ønsker forskellige konfigurationer for forskellige projekter, kan du installere det som en udviklingsafhængighed og oprette en anden konfigurationsfil for hvert projekt. Vær opmærksom på, at hvis ESLint er installeret som en projektafhængighed i modsætning til globalt, skal du køre den eksekverbare fil fra din node_modules-mappe på følgende måde:

$ ./node_modules/.bin/eslint --init

Når du kører ovenstående kommando, bliver du ført gennem konfigurationen af ESLint ved hjælp af en række spørgsmål. (Bemærk: Uanset hvor meget du planlægger at tilpasse dine lintingregler, skal du starte med dette trin, fordi ESLint har brug for den .eslintrc-fil, der vil blive genereret af denne proces, før den kan linte din kode.)

Det første spørgsmål, du bliver stillet, er, hvordan du skal konfigurere ESLint. Du har tre muligheder: Brug en populær stilguide, besvar spørgsmål om din stil, eller lad ESLint konfigurere sig selv for dig ved at inspicere dine filer for at afgøre, hvordan reglerne skal opstilles. Hvis udsigten til at konfigurere det selv med det samme virker skræmmende, kan du falde tilbage på at bruge en populær stilguide, der er udviklet af en af nogle få kendte organisationer.

Uanset hvilken vej du vælger, bruger ESLint dine svar til at generere en fil med navnet .eslintrc i den aktuelle arbejdskatalog. Det er denne fil, som du skal ændre, hvis du senere hen ønsker at foretage ændringer i lintingreglerne.

Her er et eksempel på en .eslintrc-fil i JSON-format, der bruger standardreglerne i Airbnb JavaScript-stilvejledningen og indeholder to brugerdefinerede regler for at slå strict mode fra og tillade console.log()-angivelser:

{ "extends": "airbnb-base", "rules": { "strict": "off", "no-console": "off" }}

Hvis du vælger at besvare spørgsmål om din stil, vil den spørge dig om f.eks. hvilken ECMAScript-version du bruger, om du foretrækker tabulatorer eller mellemrum, semikolon eller ej, og om du bruger JSX og/eller React. ESLint’s out-of-the-box-understøttelse af React og supplerende plugins vil sandsynligvis gøre det til det bedste valg for React-udviklere. I hvert fald for dem, der lige er kommet i gang med linting.

Når ESLint er installeret og en .eslintrc fil er blevet genereret, kan du bruge CLI’en til at komme i gang med at linting din kode. ESLint leder som standard efter din .eslintrc-fil, så du behøver ikke at angive nogen konfigurationer på kommandolinjen. Men du kan bruge forskellige flag til at ændre, hvordan ESLint opfører sig. I eksemplet nedenfor fortæller -- quiet-flaget ESLint, at det kun skal vise fejl i modsætning til både advarsler og fejl. Flaget --fix fortæller den, at den skal forsøge at rette alle de fejl, den finder, automatisk.

// run eslint against file1.js$ ./node_modules/.bin/eslint file1.js// run eslint against file1.js and file2.js with flags to modify behavior$ ./node_modules/.bin/eslint file1.js file2.js --quiet --fix

Som med de andre CLI’er, vi har gennemgået, kan du bruge jokertegn og filstier i stedet for specifikke filnavne, hvis det er nødvendigt. Selv om ESLint kan konfigureres i høj grad, letter det indlæringskurven ved at bruge en lettilgængelig opsætningsvejledning til sin standardkonfigurationsmetode. Hvis du virkelig vil gå i dybden med tilpasninger, indeholder den officielle dokumentation gode forklaringer på alt, hvad du kan gøre med ESLint.