ESLint: De væsentligste fakta om vigtige frontendværktøjer

For nylig har jeg været mere involveret i front-end-udvikling. Jo mere jeg gør, jo mere går mit sind og min sjæl vild i sin kaotiske verden. Selv en simpel To-Do-List-app kan let kræve en masse værktøjer - ESLint, Babel, Webpack, for at nævne nogle få - og pakker bare for at komme i gang.

Heldigvis er der mange startpakker derude, så vi ikke behøver at gøre alt fra bunden. Med dem er alt allerede konfigureret, så vi kan begynde at skrive den første kodelinje med det samme. Det sparer tid på gentagne, kedelige opgaver, hvilket kan være godt for erfarne udviklere.

Denne fordel kommer dog med en pris for begyndere. Da alt fungerer ud af kassen, virker det som magi, og de ved muligvis ikke, hvad der virkelig sker under emhætten, hvilket er vigtigt at forstå på et eller andet niveau. Selvom læringskurven ikke er så stejl som andre - prøv at sammenligne med nogle værktøjer, du har lært og brugt, får du hvad jeg mener - i denne kaotiske verden har vi brug for en overlevelsesguide til rejsen.

Denne serie vil dække grundlæggende værktøjer til front-end-udvikling og hvilke vigtige ting, vi har brug for at vide om dem. Dette giver os mulighed for at styre værktøjerne i stedet for at blive kontrolleret af dem.

I det vil vi fokusere på udvikleroplevelsen af ​​hvert af disse værktøjer. Så målet med denne serie er at fungere som en overlevelsesguide og give et overblik på højt niveau af hvert værktøj, ikke at tjene som dokumentation.

Hvad vil blive inkluderet:

  • ESLint <- Vi er her
  • Babel
  • Webpack
  • Flyde
  • Typescript
  • Spøg.

Nok af et forord, lad os komme i gang med det første værktøj: ESLint.

Hvad er ESLint, og hvorfor skal vi bruge det?

ESLint er, som navnet antyder, en linter til ECMAScript. Og definitionen af ​​en linter er:

en maskine til fjernelse af korte fibre fra bomuldsfrø efter egrenering.

Selvom kode og bomuldsfrø ikke har noget forhold, uanset kode eller bomuldsfrø, vil en linter hjælpe med at gøre tingene renere og mere konsistente. Vi ønsker ikke at se koden sådan:

const count = 1; const message = "Hello, ESLint" count += 1 

Det ser både grimt ud og har en fejltagelse. Her er når ESLint træder ind for at hjælpe med det. I stedet for at lade fejlen dumpes til browserkonsollen, når vi kører koden, fanger ESLint den, når vi skriver (ikke rigtig: vi skal bruge editor- eller IDE-udvidelser til dette, som vil blive dækket senere).

Selvfølgelig er denne fejl ikke vanskelig at finde ud af, men ville det ikke være pænere at have en assistent, der minder os om, hver gang vi er ved at lave en fejl og måske rette den automatisk til os? Selvom ESLint ikke kan fange alle mulige fejl, sparer det os i det mindste en anstrengelse, så vi kan bruge tid på andre ting, der betyder noget og har brug for menneskelig opmærksomhed.

Hvordan fungerer ESLint?

Nu hvor vi ved, hvad ESLint er, og hvorfor vi har brug for det, lad os gå lidt dybere og se, hvordan det fungerer. I det væsentlige kan vi nedbryde det til tre store trin.

Parser

Koden, vi skriver, er intet andet end en række tegn. Denne sekvens er imidlertid ikke kun tilfældige tegn: de skal følge et sæt regler eller konventioner, som er grammatikken, der danner et sprog.

For et menneske tager det os lidt at gå fra at læse tekst eller kode til at forstå det begrebsmæssigt. For en computer er dette meget sværere at opnå. For eksempel:

const tool = 'ESLint' // 1 const tool = "ESLint" // 2 

Når vi læser de to linjer ovenfor, ved vi straks, at de er identiske og kan læses som "der er en konstant navngivet toolmed værdien af ​​ESLint". For en computer, der ikke forstår betydningen, ser disse to linjer helt anderledes ud. Som et resultat, hvis vi fodrer i rå kode til ESLint, er det næsten umuligt at gøre noget.

Når ting bliver komplicerede og svære at kommunikere - tænk på, hvordan vi kan have en computer til at forstå, hvad vi gør - abstraktion kan være en flugt. Ved at abstrahere en ting skjuler vi alle unødvendige detaljer, reducerer støj og holder alle på samme side, hvilket letter kommunikationen. I ovenstående eksempel betyder et eller to mellemrum ikke noget, heller ikke enkelt anførselstegn eller dobbelt anførselstegn.

Med andre ord, det er hvad en parser gør. Den konverterer rå kode til et abstrakt syntaks-træ (AST), og denne AST bruges som medium for fnugregler at basere på. Der er stadig mange trin, som en parser skal gøre for at oprette en AST - hvis du er interesseret i at lære mere om, hvordan en AST genereres, har denne vejledning et godt overblik.

Regler

Det næste trin i processen er at køre AST gennem en liste over regler. En regel er en logik i, hvordan man finder ud af potentielle eksisterende problemer i koden fra AST. Problemer her er ikke nødvendigvis syntaktiske eller semantiske fejl, men kan også være stilistiske. Outputtet fra en regel vil omfatte nogle nyttige oplysninger til senere brug, som kodelinjer, positioner og informative meddelelser om problemet.

Ud over at fange problemer kan en regel endda automatisk korrigere kode, hvis det er muligt. For eksempel, når der ikke anvendes flere mellemrum på koden ovenfor, vil det trimme alle overflødige mellemrum, hvilket får koden til at se ren og konsistent ud.

 const tool = "ESLint" // 2 // becomes const tool = "ESLint" // 2 

I forskellige scenarier kan en regel bruges på forskellige niveauer - fravalgt, kun advarsel eller streng fejl - og har forskellige muligheder, som giver os kontrol over, hvordan vi bruger reglen.

Resultat

Her kommer slutningen af ​​processen. Med output fra en regel er det bare spørgsmålet om, hvordan vi viser det på en menneskelig venlig måde takket være alle de nyttige oplysninger, vi nævnte tidligere. Derefter fra resultatet kan vi hurtigt påpege problemet, hvor det er, og lave en løsning, eller måske ikke.

Integration

ESLint kan bruges som et enkeltstående værktøj med sin robuste CLI, men det er en bare-ben-måde at bruge ESLint på. Vi ønsker ikke at indtaste en kommando hver gang vi vil lint kode, især ikke i et udviklingsmiljø. Løsningen på dette er at integrere ESLint i vores udviklingsmiljø, så vi kan skrive kode og se problemer fanget af ESLint alt på ét sted.

Denne form for integration kommer fra udvidelser, der er specifikke for IDE'er eller redaktører. Disse udvidelser kræver, at ESLint fungerer, da de kører ESLint bag scenen - ikke underligt, at vi stadig har brug for at installere ESLint sammen med dem, de er intet uden ESLint. Dette princip gælder for andre IDE- eller editor-udvidelser, vi bruger dagligt.

Husker du output fra en regel, vi talte ovenfor? En udvidelse bruger den til at blive vist i IDE eller editor. Hvordan nøjagtigt output vises, afhænger af, hvordan udvidelsen implementeres, og hvordan IDE eller editor er åben for dens udvidelser. Nogle udvidelser drager også fordel af evnerne til problemkorrektion fra regler til at ændre kode på gem, hvis vi aktiverer det.

Konfiguration

Konfiguration er den vigtigste kraft, der giver alsidighed til et værktøj. ESLint er ikke forskellig fra det, bortset fra at det har den mest omfattende konfiguration blandt andre værktøjer. Generelt har vi brug for en fil eller et sted for at sætte konfigurationen, og der er et par muligheder for os.

Alle koges ned til to hovedmåder: enten har vi en separat konfigurationsfil til hvert værktøj, eller vi bundter dem alle sammen package.json.  .eslintrc.jser en af ​​de filer, som ESLint vil kigge efter dens konfiguration, og også den med den højeste prioritet.

Den næste ting, vi har brug for at vide om konfiguration, er dens hierarki og kaskadeadfærd. Takket være disse funktioner behøver vi ikke have en konfigurationsfil i hver enkelt mappe i projektet.

Hvis en konfigurationsfil ikke findes i en mappe, ser ESLint simpelthen mappens forælder op til en, indtil den ikke kan finde en. Derefter falder det tilbage til den brugerdefinerede standardkonfiguration i ~/.eslintrc. Ellers tilføjer eller tilsidesætter konfigurationsfilen dem på øverste niveau.

Der er dog en særlig tweak om dette. Hvis vi specificerer root: truei en konfigurationsfil, stopper opslaget ved den fil i stedet for at gå op som før. Desuden bruger ESLint denne konfigurationsfil som rodkonfiguration, og alle underkonfigurationer vil være baseret på denne.

Dette er ikke kun begrænset til ESLint - disse ting er almindelige for andre værktøjer. Lad os tale om ESLint-specifik konfiguration.

Parser

Parserens rolle i ESLint er blevet diskuteret ovenfor. Som standard bruger ESLint Espree som sin parser. Vi kan ændre denne parser til en anden kompatibel som babel-eslint eller @ typescript-eslint / parser, hvis vi bruger henholdsvis Babel eller Typescript.

For at konfigurere parseren bruger vi parserOptions. Blandt de muligheder, der understøttes af Espree, er her nogle, som vi ofte bruger og skal være opmærksomme på:

  • ecmaVersion

Vi skal specificere den passende ECMA-version til de funktioner, vi vil bruge. For eksempel, hvis emcaVersion: 5koden nedenfor giver nogle fejl.

```javascript let a = [1, 2, 3, 4] // error due to `let` keyword var b = [...a, 5] // error due to spread syntax ``` 

Parseren kan ikke analysere koden, fordi både letnøgleordet og spredningssyntaks netop blev introduceret i ES6. Ændring emcaVersiontil 6 eller derover løser simpelthen fejlene.

  • sourceType

I dag skriver vi for det meste alt i moduler og bundter dem derefter sammen. Så denne mulighed, det meste af tiden, burde være module.

En anden værdi, vi kan bruge - såvel som standard - er script. Forskellen er, om vi kan bruge JS-moduler eller ej, dvs. brug importog exportnøgleord. Næste gang vi får denne fejlmeddelelse Parsing error: 'import' and 'export' may appear only with 'sourceType: module', ved vi, hvor vi skal se.

  • ecmaFeatures.jsx

Der kan være yderligere ES-funktioner, vi vil bruge, for eksempel JSX-syntaks. Vi bruger ecmaFeatures.jsx: truetil at aktivere denne funktion. Bemærk, at JSX-support fra Espree ikke er den samme som JSX i React. Hvis vi vil have React specifikt JSX, skal vi bruge eslint-plugin-react for bedre resultater.

Hvis vi bruger en anden parser, er disse indstillinger mere eller mindre de samme. Nogle har muligvis færre muligheder, og andre har måske flere, men de er alle defineret under parserOptions.

Miljø

Det afhænger af, hvor koden kører: der er forskellige foruddefinerede globale variabler. Vi har window, documenti browseren, for eksempel. Det ville være irriterende, hvis no-undef-reglen er aktiveret, og ESLint bliver ved med at fortælle os windoweller documentikke er defineret.

Den envmulighed er her for at hjælpe. Ved at specificere en liste over miljøer vil ESLint vide om globale variabler i disse miljøer, og lad os bruge dem uden et ord.

Der er et specielt miljø, vi skal bemærke es6. Det indstilles implicit parserOptions.ecmaVersiontil 6 og aktiverer alle ES6-funktioner undtagen moduler, som vi stadig skal bruge parserOptions.sourceType: "module"separat.

Plugins og delbare konfigurationer

At have den samme konfiguration for regler igen og igen på tværs af forskellige projekter kan være trættende. Heldigvis kan vi genbruge en konfiguration og kun tilsidesætte regler efter behov med extends. Vi kalder denne type konfigurerbare delbare konfigurationer, og ESLint har allerede to til os: eslint:recommendedog eslint:all.

Konventionelt har ESLints delbare konfigurationer eslint-configpræfiks, så vi nemt kan finde dem via NPM med eslint-confignøgleord. Blandt hundredvis af resultater er der nogle populære, som eslint-config-airbnb eller eslint-config-google, du hedder det.

Uden for boksen har ESLint en række regler, der tjener forskellige formål fra mulige fejl, bedste praksis, ES6 til stilistiske problemer. Desuden har ESLint et stort antal tredjepartsregler, der leveres af næsten tusind plugins, for at overbelaste sin evne. I lighed med delbare konfigurationer er ESLints plugins forud for eslint-pluginog er tilgængelige på NPM med eslint-pluginnøgleordet.

Et plugin definerer et sæt nye regler, og i de fleste tilfælde afslører det sine egne praktiske konfigurationer. For eksempel giver eslint-plugin-react os to delbare konfigurationer, eslint-plugin-react:recommendedog eslint-plugin-react:allligesom eslint:recommendedog eslint:all. For at bruge en af ​​dem skal vi først definere plugin-navnet og for det andet udvide konfigurationen.

{ plugins: ["react"], extends: "plugin:react/recommended" } // Note that we need to prefix the config by `plugin:react` 

Et almindeligt spørgsmål at stille er, hvilke plugins eller configs der skal bruges. Selvom det i høj grad afhænger af vores behov, kan vi bruge Awesome ESLint som en reference til at finde nyttige plugins såvel som configs.

Pænere

Vi er næsten der - vi er næsten kommet til slutningen. Sidst men ikke mindst diskuterer vi et populært par ESLint, Prettier. Kort sagt er Prettier en meningsfuld kodeformater. Selvom Prettier kan bruges alene, forbedrer integrationen af ​​det til ESLint oplevelsen meget, og eslint-plugin-prettier gør dette job.

Forskellen mellem at bruge Prettier alene og at bruge Prettier med ESLint kan opsummeres til kodeformatering som et problem. I stedet for at give formatproblemer separat, vil kørsel af Prettier med ESLint behandle formatproblemer ligesom andre problemer. Disse problemer kan dog altid løses, hvilket svarer til formatering af koden.

Sådan eslint-plugin-prettierfungerer det. Det kører Prettier som regel bag scenen og sammenligner koden før og efter at være kørt gennem Prettier. Endelig rapporterer den forskelle som individuelle ESLint-problemer. For at løse disse problemer bruger pluginet simpelthen den formaterede kode fra Prettier.

For at få denne integration skal vi installere både prettierog eslint-plugin-prettier. eslint-plugin-prettierleveres også med eslint-plugin-prettier:recommendedconfig — som udvides eslint-config-smukkere. Derfor skal vi også installere for eslint-config-prettierat bruge det.

{ "plugins": ["prettier"], "extends": "plugin:prettier/recommended" } 

Konklusion

Kodefodre eller formaterere er blevet de facto-standarden inden for softwareudvikling generelt, og ESLint specifikt inden for front-end-udvikling.

Dens fordele går langt ud over, hvad det gør teknisk, da det hjælper udviklere med at fokusere på vigtigere forhold. Takket være delegering af kodestyling til en maskine kan vi undgå meningsfulde stilarter ved kodegennemgang og bruge den tid i stedet til mere meningsfuld kodegennemgang. Kodekvalitet har også fordel, og vi får mere ensartet og mindre fejlbenyttet kode.

Denne artikel blev oprindeligt sendt på min blog .