Du kan nästan alltid slå vad om att en bra text har gynnats av en bra redigering. I detta avseende är kod inte annorlunda än prosa. En av de fördelar vi har som utvecklare och programmerare är redaktörer, eller kodlinter, som kan byggas in i våra arbetsflöden.
Linting är handlingen eller processen att kontrollera din kod för fel av något slag. Det finns många tankar om hur man kan optimera effektiviteten hos ett givet stycke kod. Men att kontrollera att den är felfri och följer en viss stilguide är baslinjen. Ibland handlar det om konsistens och läsbarhet, ibland handlar det om att koden överhuvudtaget ska kunna köras.
När det gäller JavaScript linting finns det en handfull verktyg som sticker ut. Låt oss titta på fyra linters som kan hjälpa dig att komma igång eller förfina din lintingprocess: JSLint, standardJS, JSHint och ESLint.
JSLint
JSLint skapades 2002 av Douglas Crockford, som också skrev en av de bästa böckerna om JavaScript. JSLint ger enkelhet och snabbhet. Men den är också mycket åsiktsstyrd, vilket kan vara en välsignelse eller en förbannelse.
JSLint består av en enkelsidig webbplats som domineras av ett textfält där du kan klistra in din kod. Klicka på knappen ”JSLint” och eventuella fel, stilistiska, syntaktiska eller andra, visas under textfältet. Under textfältet finns en liten lista med alternativ som kan konfigureras med hjälp av kryssrutor. Bland alternativen finns att tolerera extra vitrymder, användning av nyckelordet ”this” (vilket Crockford avråder från i sina föredrag) och inkludering av Node.js.
Om du inte är bunden till någon särskild stilguide och vill ha en pålitlig källa som kontrollerar din kod åt dig, är JSLint ett utmärkt alternativ. Det är särskilt effektivt för att testa kodstycken eller om du letar efter ett sätt att snabbt lintra små projekt – kanske en statisk webbplats med en enda sida som bara innehåller en JavaScript-fil.
standardJS
Baserat enbart på GitHub-stjärnor är standardJS det mest populära alternativet med nästan 19 000 stjärnor. Det är helt åsiktsstyrt, vilket innebär att det inte är anpassningsbart överhuvudtaget. Men om du inte är bunden till någon särskild stilguide kan detta vara en välsignelse. Den kommer i form av ett Node CLI och kan installeras globalt eller som ett utvecklingsberoende med hjälp av din terminal eller valfri kommandorad:
$ npm install standard --global
// or
$ npm install standard --save-dev
Eftersom standardJS har Node och npm som förutsättningar, och eftersom den körs från kommandoraden eller genom ett npm-skript, höjs ribban något från JSLints nivå. Men eftersom den inte är konfigurerbar har du inte mycket annat att oroa dig för. Du kan köra den från kommandoraden som ett enordskommando och den kommer att kontrollera varje fil med ett .js
tillägg i din nuvarande arbetskatalog.
Alla fel som den hittar kommer att skrivas ut till din terminal eller kommandorad. Du kan förvänta dig att se utdata som liknar det här exemplet från standardJS-dokumentationen:
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
Om du behöver ange en fil eller katalog kan du inkludera sökvägen som ett argument och använda jokertecken. Den accepterar också jokertecken. I det här exemplet söker och lintar standardJS alla JavaScript-filer i katalogen src
och dess underkataloger:
$ standard "src/**/*.js" --fix
Flaggan --fix
efter filsökvägen är ett alternativ för att automatiskt åtgärda fel när de hittas. Detta kan vara en stor tidsbesparing, men det kan också vara en bra inlärningsövning att rätta felen själv.
Om du vill utforska de konventioner och regler som standardJS använder sig av innan du bestämmer dig för om du ska använda den eller inte, finns en fullständig lista här. StandardJS är ett bra alternativ för dig som letar efter ett snabbt och pålitligt sätt att komma igång med en JavaScript-linter.
JSHint
JSHint började som en fork av JSLint. Målet var att göra en mer konfigurerbar linter. Om du har använt standardJS, eller en annan åsiktsstyrd linter, och du letar efter ett sätt att börja anpassa dina egna lintingregler, kan JSHint vara något för dig. Den har de flesta av fördelarna med de tidigare nämnda linters och lite till.
Likt JSLint har JSHints hemsida ett textfält där du kan klistra in kod. Fältet Metrics
till höger om textfältet uppdateras i realtid när du skriver och sammanställer en löpande lista med statistik om din kod, t.ex. en räkning av hur många funktioner den innehåller. Naturligtvis visas också alla lintingfel som hittas.
Om du inte gillar copy/paste-metodiken och vill baka in den i ditt projekt kan JSHint installeras globalt eller som ett projektberoende med hjälp av npm:
$ npm install jshint --global
// or
$ npm install jshint --save-dev
När den väl är installerad använder du CLI:n för att linta din kod. Här är två exempelkommandon som kontrollerar en enskild fil respektive en katalog:
$ jshint index.js
// or
$ jshint src/
I det första exemplet lintar JSHint filen index.js
och i det andra söker JSHint rekursivt i katalogen ”src/” och lintar alla JavaScript-filer den hittar. JSHint skriver ut alla fel den hittar i din terminal.
Om du inte bryr dig om anpassningar kan JSHint användas som beskrivet i exemplen ovan och det kommer att fungera alldeles utmärkt. Men härifrån kan komplexiteten öka avsevärt eftersom JSHint är helt konfigurerbart och dessutom har ett API, vilket innebär att det kan användas som en JavaScript-modul i dina egna JavaScript-filer.
En anpassad konfiguration, som bör lagras i en fil med namnet .jshintrc
, kan se ut så här:
{
"esversion": 5,
"eqeqeq": true,
"strict": true
}
Detta exempel, från toppen till botten, ställer in ECMAScript-versionen på 5, kräver användning av tre likhetstecken ( ===
eller !==
) i motsats till två (==
eller !=
) vid jämförelse av värden och upprätthåller strikt läge. Du kan inkludera dina anpassade konfigurationer genom att ange sökvägen till din .jshintrc
-fil bakom en -- config
-flagga på kommandoraden eller genom att deklarera dem som attributet ”jshintConfig” i ditt projekts package.json
-fil. JSHint kommer att använda sina standardalternativ för alla regler som du inte anpassar.
Kommandoradsalternativet kan se ut så här:
// looks for '.jshintrc' in the current directory
$ jshint --config './.jshintrc'
Medans package.json
-alternativet kan se ut så här:
{
"jshintConfig": {
"esversion": 5,
"eqeqeq": true,
"strict": true
}
}
Du kan använda dessa grunder för att komma igång med att anpassa dina egna lintingregler med JSHint. Om du letar efter mer innehåller den officiella dokumentationen en uttömmande beskrivning av hur du använder JSHint API och alla sätt som det kan anpassas för att passa dina behov.
ESLint
GitHub-stjärnor åsido, när det gäller JavaScript linting så är ESLint troligen den lint som ses mest i det vilda och som kommer att vara det vanligaste alternativet för många människor. I sin egen dokumentation jämför den sig själv med JSLint och JSHint när det gäller de metoder den använder för att analysera JavaScript. Och i likhet med JSHint kan du enkelt börja med att använda standardvärden och lägga till anpassningar när dina preferenser eller behov förändras.
Om du vill komma igång med ESLint kan du installera det globalt eller som ett utvecklingsberoende:
$ npm install eslint --save-dev
// or
$ npm install eslint --global
Om du installerar ESLint globalt kommer dess konfigurationer att gälla för alla projektfiler som du kör det mot. Men om du vill ha olika konfigurationer för olika projekt kan du installera den som ett utvecklingsberoende och skapa en annan konfigurationsfil för varje projekt. Var medveten om att om ESLint installeras som ett projektberoende, i motsats till globalt, måste du köra den körbara filen från din node_modules
-mapp på följande sätt:
$ ./node_modules/.bin/eslint --init
När du kör kommandot ovan kommer du att gå igenom konfigureringen av ESLint med hjälp av en rad frågor. (Obs: Oavsett hur mycket du planerar att anpassa dina lintingregler måste du börja med det här steget eftersom ESLint behöver .eslintrc
-filen som kommer att genereras av den här processen innan den kan lintra din kod.)
Den första frågan som ställs till dig är hur du ska konfigurera ESLint. Du har tre alternativ: Använd en populär stilguide, svara på frågor om din stil eller låt ESLint konfigurera sig självt åt dig genom att inspektera dina filer för att avgöra hur reglerna ska sättas upp. Om utsikten att konfigurera det själv direkt från början verkar skrämmande kan du falla tillbaka på att använda en populär stilguide som utvecklats av en av några få kända organisationer.
Oavsett vilken väg du väljer kommer ESLint att använda dina svar för att generera en fil med namnet .eslintrc
i den aktuella arbetskatalogen. Det är denna fil som du kommer att ändra om du vill göra ändringar i lintingreglerna senare på vägen.
Här är ett exempel på en .eslintrc
-fil i JSON-format som använder standardreglerna i Airbnbs JavaScript-stilguide och innehåller två anpassade regler för att stänga av strikt läge och tillåta console.log()
-angivelser:
{
"extends": "airbnb-base",
"rules": {
"strict": "off",
"no-console": "off"
}
}
Om du väljer att svara på frågor om din stil kommer den att fråga dig till exempel vilken ECMAScript-version du använder, om du föredrar tabulatur eller mellanslag, semikolon eller inte, och om du använder JSX och/eller React. ESLints out-of-the-box-stöd för React och kompletterande plugins kommer sannolikt att göra det till det bästa valet för React-utvecklare. Åtminstone för dem som precis har börjat med linting.
När ESLint är installerat och en .eslintrc
fil har genererats kan du använda CLI för att komma igång med linting av din kod. ESLint letar efter din .eslintrc
-fil som standard så du behöver inte ange några konfigurationer på kommandoraden. Men du kan använda olika flaggor för att ändra hur ESLint beter sig. I exemplet nedan talar flaggan -- quiet
om för ESLint att endast visa fel i stället för både varning och fel. Flaggan --fix
säger att den ska försöka rätta alla fel som den hittar automatiskt.
// 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 andra CLI:erna som vi har diskuterat kan du använda jokertecken och filsökvägar i stället för specifika filnamn om det behövs. Även om ESLint är mycket konfigurerbart underlättar det inlärningskurvan genom att använda en lättillgänglig installationsguide för sin standardmetod för konfiguration. Om du verkligen vill gräva i anpassningar innehåller den officiella dokumentationen bra förklaringar till allt du kan göra med ESLint.
Nästa steg och slutsats
Sammanfattningsvis:
- JSLint är bra för att kontrollera snippets eller enstaka filer. En av dess potentiella nackdelar är att den inte är lämplig för stora projekt.
- StandardJS är idealisk för dem som vill komma igång med lite eller inget krångel och/eller bygga in en linter i sina arbetsflöden och byggskript. Men den är inte konfigurerbar. Så om du behöver göra egna regler vill du förmodligen titta på JSHint eller ESLint.
- JSHint kan också installeras via npm och dess lintingregler är helt konfigurerbara. Detta kan vara bra eller dåligt, beroende på dina behov och din kunskapsnivå. Du kan börja med standardreglerna och anpassa dem efter behov. Den har också en webbplats med en enda sida som du kan använda för att lintra utdrag eller enskilda filer.
- ESLint kan installeras via npm och byggas in i arbetsflöden precis som JSHint. Och fråga- och svarsformatet i dess CLI kan hjälpa dig att lära dig när du kommer igång. I sin out-of-the-box-form innehåller den branschstandardiserade stilguider och lintingregler med öppen källkod som kan tillämpas på alla projekt.
Alla fyra linter som vi har tittat på är pålitliga och välrenommerade i kraft av att de används och utvecklas av välkända personer och organisationer i webbutvecklingsgemenskapen. Vem som helst skulle vara väl betjänt av någon av dem. Om du behärskar grunderna som diskuteras i den här artikeln är ett bra nästa steg att lära dig att integrera dem ytterligare i ditt arbetsflöde med hjälp av npm-skript eller en buntler som Webpack.
Varje verktyg är bara så bra som den användning du får ut av det. Detta gäller för linters och för koden som de hjälper dig att finslipa. Även om du utvecklar ensam och inte behöver oroa dig för kodkonsistens i ett team av utvecklare kan du ändå dra nytta av en inbyggd redigerare. Det är ett otroligt effektivt sätt att lära sig att skriva JavaScript korrekt. Oavsett vilken linter du använder kan det bara hjälpa dig att använda en linter. Du kan vara säker på att kvaliteten på din kod kommer att förbättras, liksom din skicklighet som utvecklare.
LogRocket: Debugga JavaScript-fel enklare genom att förstå sammanhanget
Debuggning av kod är alltid en tråkig uppgift. Men ju mer du förstår dina fel desto lättare är det att åtgärda dem.
LogRocket låter dig förstå dessa fel på nya och unika sätt. Vår lösning för övervakning av frontend spårar användarnas engagemang i dina JavaScript-frontends för att ge dig möjlighet att ta reda på exakt vad användaren gjorde som ledde till ett fel.
LogRocket registrerar konsolloggar, sidladdningstider, stacktraces, långsamma nätverksförfrågningar/-svar med rubriker + kroppar, webbläsarmetadata och anpassade loggar. Det har aldrig varit enklare att förstå effekterna av din JavaScript-kod!
Prova det gratis.