Code-Qualität ist mittlerweile keine Verhandlungssache mehr. Tools wie Prettier sorgen für die korrekte Formatierung eures Codes, mit ES-Lint oder JS-Hint lassen sich Konventionen durchsetzen, sodass eine Codebase maintainable bleibt. Nur für package.json-Skripte gibt es (bisher) weder derartige Standards, noch ein Tool, das für deren Durchsetzung sorgt. Dabei sind sie eigentlich ein wichtiger Teil der Node-Entwickler-Experience: Ihr braucht sie, um Projekte zu starten, Entwicklungsumgebungen auszuführen und für Formatierung, Linting und Tooling.

Ein Ansatz, ein gewisses Maß an Ordnung in die Script-Section zu bringen, ist nps, ein Package, das es erlaubt, eure Skripte von der package.json in eine package-scripts.js oder sogar in eine package-scripts.yaml-Datei zu bewegen – das hat zum Beispiel den Vorteil, dass ihr die Skripte zumindest direkt in der Datei kommentieren könnt, um auch morgen noch zu wissen, welches wofür da ist. Für Einheitlichkeit bei der Benennung sorgt das Tool aber nicht.

Moritz Jacobs hat in seiner Funktion als Entwickler einer Augsburger Agentur oft genug mit großen Codebases zu tun, bei denen genau das nicht gegeben ist. Große Repositories mit unterschiedlichen Projekten, die alle über eine eigene package.json verfügen, in der alle Skripte unterschiedlich benannt sind, übergeben zu bekommen, ist in seinem Arbeitsalltag keine Seltenheit. Sich jeweils pro Repo merken zu müssen, was genau jetzt durch npm run start getriggert wird, fand er einfach nicht besonders effizient.

Das Problem dabei: Es gibt keinen Standard dafür. Design und Benennung von npm-Skripten liegen in der Verantwortung des Einzelnen, es gibt keine Richtlinien, die als Best Practice gelten. Ein Weg wäre jetzt, einfach ein Paper zu veröffentlichen, in dem mögliche Best Practices diskutiert werden und zu hoffen, dass es irgendjemand lesen und die Community dem zustimmen würde. Jacobs und sein Team haben sich stattdessen dafür entschieden, mit Scriptlint ein CLI- Tool zu designen. Ähnlich wie ES-Lint dafür sorgt, dass ihr nur JS-Code committed, der gewissen Standards entspricht, die ihr allerdings costumizen und ergänzen könnt, sorgt Scriptlint für Ordnung bei der Benennung und Struktur eurer Skripte innerhalb der package.json eines Projekts.

Das Tool verfügt über zwei Modi. Im Default-Mode werden nur einige grundlegende Regeln durchgesetzt:

Eure package.json muss ein "test"-Script (nicht das Default-Script von npm init), ein "dev"– und ein "start"-Script beinhalten:

{
    "scripts": {
        "start": "...",
        "test": "...",
        "dev": "...",
    }
}

Im Strict-Mode sorgt das Tool außerdem für die Einhaltung folgender Vorgaben:

Entwickler sollen Namespaces nutzen, um die Skripte zu kategorisieren und diese durch : zu trennen. Die Namen eurer Skripte dürfen nicht denen der Implementation entsprechen, bei "jest": "jest" würde das Tool entsprechend meckern, "test": "jest" wäre akzeptiert.

Zudem sortiert Scriptlint eure Skripte in alphabetischer Reihenfolge, kontrolliert, ob alle Skript-Namen in Camel-Case geschrieben sind und legt fest, dass es ein Trigger-Script für alle Hooks geben muss – das heißt, ein Skript wie "prepublish": "run lint" wird nur akzeptiert, wenn es auch ein "publish":"..."-Skript gibt. Auch die verbreitete Praxis, für sequentielle oder parallele Ausführung & respective && zu verwenden, kreidet das Tool im Strict-Mode an. Das heißt aber nicht, dass ihr stattdessen eure Skripte jeweils über ein separates Terminal ausführen müsst, dafür könnt ihr zum Beispiel ein Tool wie concurrently nutzen.

Wer grundsätzlich Verwendung für Scriptlint finden würde, sich aber an einzelnen Punkten, wie beispielsweise der alphabetischen Sortierung störe, könne ungewünschte Features auch ausschalten, so Jacobs im Gespräch mit t3n. Innerhalb der Agentur würde das Tool bereits fleißig genutzt und das Team um das Projekt feile fleißig daran weiter. Wer sich beteiligen möchte: Pull-Requests sind natürlich herzlich willkommen.

Passend dazu: Destiny: Prettier für die File-Struktur eurer Codebase