Spectral is een open source linter waarmee je regels voor API-documentatie vastlegt in een ruleset en die vervolgens automatisch controleert. Die tool ligt onder vuur. Er staan honderden issues en pull requests open, de VS Code-plugin loopt achter, en half juli kwam daar een supply chain-incident in een van de dependencies bovenop. Dat laatste was voor veel mensen de druppel. Omdat onze eigen tooling op Spectral draait en de API Design Rules ermee beschreven zijn, uitten veel mensen daar terecht hun zorgen over. Ons antwoord: we slopen Spectral er niet halsoverkop uit, want er zit juist beweging in de richting die we toch al op wilden. Hieronder leggen we uit waar we staan en wat we doen.

Binnen modern web-development zijn er veel processen waarbij we NPM-packages gebruiken. De meest herkenbare verschijningsvormen van NPM-packages zijn libraries en frameworks, maar in de afgelopen jaren is het scala behoorlijk uitgebreid.

In veel codebases zie je ook: linters , test-engines, type-definitions en CLI-tools. Deze groei is verklaarbaar maar zorgt wel voor een stijging van het aantal dependencies binnen projecten. En dat zorgt weer voor problemen als: de welbekende dependency-hell, grote hoeveelheden onderhoudswerk en trage transpile-processen.

In deze post duiken we wat dieper in het NPM-ecosysteem en lees je hoe je bovenstaande problemen kunt voorkomen.

In de meeste projecten is dit de perceptie: node_modules worden door package managers geinstalleerd en zijn dus geen source code die in een git repository thuis hoort. Deze blog post probeert je aan het denken te zetten. Niet om je te overtuigen dat het altijd een goed idee is om node_modules in git repositories te zetten, maar om te realiseren dat in sommige projecten het verstandig kan zijn.