👮 Linting
Iedere developer heeft z'n eigen programmerstijl. En dat slaat helemaal nergens op; want iedereen weet dat een beschaafd mens zijn code afsluit met een puntkomma.🙄 Om dat probleem op te lossen zijn er linters uitgevonden. Een linter checkt de code van je collega's op patronen die jouw niet zinnen en verbeterd deze. Maar naast politieagentje spelen zijn ze er ook - stiekem is dit het belangrijkst - om vroegtijdig bugs en foutjes te detecteren in je code. Voor als je te lui bent om TypeScript te gebruiken.
Maar nu blijkt dus dat je niet alleen je JavaScript stijl kunt forceren op je collega's! Er zijn dus ook CSS-linters, en HTML-linters. Ik ga me in dit wiki-artikel alleen focussen op Javascript linters omdat het gros van blok tech bestaat uit Javascript.
Volgens deze collectie van GitHub zijn er een aantal populaire linters beschikbaar:
Interessant, want ik had eigenlijk alleen gehoord van ESLint door mijn stage. Terwijl Standard de meeste sterren verzameld heeft.
Het onderscheid wordt gemaakt in de configuratie van die linters. Die heeft Standard namelijk niet, in tegenstelling tot JSHint én ESLint. Dus voor standard is het plug-and-play. Mooi voor als je weinig verstand hebt van Linters zoals ik. Maar ik wil er toch graag meer over leren, dus valt standard eigenlijk af voor dit onderzoek.
Maar dan blijven er dus twee over: ESLint en JSLint. Zoals de naam doet vermoeden, zit er vrij weinig verschil in de twee. Ze doen allebei vrijwel hetzelfde met als uitzondering dat ESLint iets bredere ondersteuning kent en een plugin-like configuratie. Elke regel is namelijk een plugin. Vrij handig lijkt mij. Daarnaast is ESLint ook een stuk populairder. Dus ik ga voor ESLint.
Het begint allemaal met het ESLint configuratiebestand. Die je na het installeren van ESLint kunt initialiseren met npm init @eslint/config. Je wordt vervolgens geconfronteerd met een aantal configuratie-opties. Ik ga voor: syntax, find problems, and enforce code style. Vervolgens wordt gevraagd welk type modules mijn project gebruikt. Aangezien ik require() gebruik ga ik voor CommonJS. De code moet zowel in de browser als in node draaien en ik ga - voor nu - voor een populaire style guide. En laat die van standard er nou net tussen staan. Dus uiteraard gaan we voor die.
In de root van mijn project staat nu een nieuw bestandje: .eslintrc.js waarin een aantal configuratie-opties staan:
module.exports = {
env: {
browser: true,
commonjs: true,
es2021: true,
node: true
},
extends: [
'standard'
],
parserOptions: {
ecmaVersion: 'latest'
},
rules: {
}
}Nu wordt het leuk, want in de rules sectie kun je je eigen regeltjes plaatsen. Bijvoorbeeld dat je collega's gewoon die puntkomma gaan neerzetten:
module.exports = {
env: {
browser: true,
commonjs: true,
es2021: true,
node: true
},
extends: [
'standard'
],
parserOptions: {
ecmaVersion: 'latest'
},
rules: {
"semi": ["error", "always"]
}
}Nu kunnen we npx eslint serve.js gebruiken om een bestand te linten! En ik krijg gelijk 62 errors. Oeps. En dat klopt wel, want ik blijk heel inconsistent te zijn in het gebruik van double quotes en single quotes.
Na het oplossen van die single quotes blijf ik nog achter met zo'n 50 andere errors. En ik moet de hele tijd npx eslint serve.js intypen in m'n terminal. Vervelend, maar gelukkig heb ik net extensies onderzocht voor m'n IDE. En heeft de mijne automatische ESLint detectie. En wordt ik gelijk met mijn eigen falen geconfronteerd:
Gelukkig kan ik nu het hele bestand in één keer fixen:
En inderdaad, geen enkele error meer:
Nou heb ik aan het begin van de configuratie syntax, find problems, and enforce code style aangeklikt. Maar die laatste, enforce code style is stiekem eigenlijk niet helemaal de taak van de linter. Daar zijn formatters namelijk voor bedoeld. Een snelle google query geeft gelijk 2 populaire formatters terug: Prettier en Standard. Standard hebben we al eerder besproken, dus de keuze valt op Prettier.
Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary. https://github.com/prettier/prettier
Klinkt indrukwekkend, maar die configuratie van ESLint blijft wel een beetje steken. Dat gaat botsen namelijk. Gelukkig heeft Prettier op haar website een artikel geschreven hoe je ESLint en Prettier tegelijk gebruikt.
Na het volgen van de Getting Started run je npx prettier --write om alle bestanden in je project door prettier te laten formatten. En eigenlijk veranderde er vrij weinig, op de single quotes van ESLint na. Jammer, want ik vond die eigenlijk wel wat cleaner eruit zien. Dus in de .prettierrc.json heb ik deze regel toegevoegd:
{
"singleQuote": true
}En nu is alles perfect.
Iets wat ik regelmatig voorbij heb zien komen tijdens mijn onderzoek naar Linters & Formatters is Continuous Integration. Volgens Google:
Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project.
En waar het op neer komt is dat dat je linters en formatters automatisch kunt uitvoeren (maar ook, bijvoorbeeld, automatisch je code kunt uploaden naar een server. Of tests kunt uitvoeren). Dat klinkt cool dus wil ik het ook.
Husky is zo'n tool.
Modern native Git hooks made easy. Husky improves your commits and more 🐶 woof!
Klinkt goed! Gelukkig - en niet geheel ontoevallig - heeft Prettier een kleine tutorial hoe je Husky gebruikt om Prettier automatisch te laten uitvoeren. https://prettier.io/docs/en/precommit.html samen met lint-staged wordt m'n code nu elke keer dat ik een bestand toevoeg aan Git door prettier geformat!