Schnellere und verbesserte Tests für JavaScript-Projekte mit Lockfiles

In den vergangenen Monaten haben wir intensiv daran gearbeitet, unsere Lockfile-Unterstützung sowohl in der CLI als auch in der SCM-Integration zu verbessern. Die neue Funktionalität ist bereits in der CLI verfügbar und wird derzeit schrittweise im Web eingeführt. In Kürze wird sie standardmäßig für alle Organisationen aktiviert.

Viele Node.js-Projekte verwenden entweder yarn.lock oder package-lock.json, damit Entwickler:innen reproduzierbare Installationen erhalten und Umgebungen für eine bessere Zusammenarbeit synchronisieren können.

Lockfiles sind zweifellos äußerst nützlich – ihre Verwendung hat stark zugenommen. Wir haben daran gearbeitet, unsere Lockfile-Unterstützung für alle Nutzer:innen zu verbessern, um noch genauere Testergebnisse und eine deutlich höhere Performance zu erzielen.

Warum brauchten wir eine bessere Lockfile-Unterstützung in der CLI?

Bis vor Kurzem haben wir dienode_modules durchsucht, um alle Abhängigkeiten zu erfassen, die auf der Festplatte installiert waren. Das hat sich als recht langsam und mitunter ungenau erwiesen, danode_modules oft längst entfernte Abhängigkeiten enthielt, die vom Projekt gar nicht mehr verwendet wurden. Auch wenn wir uns alle bemühen, alles auf dem neuesten Stand zu halten, ist es schlicht nicht praktikabel, immer den Ordner node_modules zu löschen und alles von Grund auf neu zu installieren, um sicherzustellen, dass nur die tatsächlich im Projekt verwendeten Pakete vorhanden sind.

Wir träumten von einer Welt, in der Nutzer:innen ihre Pakete nicht installieren müssen, damit wir einen Test durchführen können. Nach einiger Planung haben wir eine neuenode-lockfile-parser-Bibliothek entwickelt, die das Lockfile selbst und die Datei package.json statt des gesamtennode_modules-Ordners durchsuchen kann. Dadurch profitieren Sie heute von deutlich besserer Performance und Genauigkeit.

Ist in einem Projekt eineyarn.lock- oderpackage-json.lock-Datei vorhanden, erkennen wir dies automatisch und verarbeiten das Projekt als Lockfile-basiert. Für Projekte ohne Lockfiles bleibt die bisherige Unterstützung unverändert bestehen.

Hinweis:

• snyk patch und derwizard benötigen weiterhin einen vorhandenennode_modules-Ordner, da Patches direkt auf die Ordner der installierten Pakete angewendet werden müssen.

• Bei Yarn-Projekten mit Node-Versionen unter 6 wird weiterhin auf dienode_module-Durchsuchung zurückgegriffen. Der Grund dafür ist, dass eine zum Parsen des Lockfiles verwendete Yarn-Bibliothek Node-Versionen unter 6 nicht unterstützt.

Welche Auswirkungen hat das auf meine Web-Projekte?

Beim Importieren eines Projekts über Github, GitLab oder Bitbucket haben wir uns bisher ausschließlich auf die Dateipackage.json gestützt, um die Abhängigkeiten des Projekts zu ermitteln. Dadurch mussten wir Annahmen über die genaue Version jedes auf der Festplatte installierten Pakets treffen und sind immer vom bestmöglichen Fall ausgegangen (also von der jeweils neuesten Version, die den in der Dateipackage.json definierten Semver-Bereich erfüllt).

Mit der zusätzlichen Unterstützung von Lockfiles können wir nun genauere Testergebnisse liefern. Ein Snyk-Test erstellt heute einen Abhängigkeitsbaum auf Grundlage der exakt aufgelösten Versionen aller Pakete im Lockfile. Dadurch können beim nächsten Snyk-Test bisher nicht gemeldete Sicherheitslücken entdeckt werden. Keine Sorge: Wenn die Einstellung für Autofix-PRs/MRs aktiviert ist, wird das wie gewohnt aktualisiert. Außerdem erhalten Sie Benachrichtigungen zu weiteren Möglichkeiten, die gemeldeten Sicherheitslücken zu beheben.

Erstellt Snyk die Lockfiles für mein Projekt neu?

Noch nicht. Wir arbeiten intensiv daran, diese Funktionalität für Yarn- und npm-Projekte bereitzustellen. Das ist keine leichte Aufgabe, da sich die interne Paketauflösungslogik von Yarn und npm sowie die Lockfiles erheblich unterscheiden.

Bis dahin müssen alle Pull Requests wie bisher manuell angepasst werden. Projekte mit Dateien vom Typ yarn.lock und package-lock.json benötigen daher vor dem Zusammenführen des Pull Requests eine aktualisierte Lockfile, wenn sich die Datei package.json geändert hat.