Des tests plus rapides et améliorés pour les projets JavaScript basés sur des fichiers lock

Depuis quelques mois, nous travaillons activement à améliorer la prise en charge des fichiers lock, dans la CLI comme dans l’intégration SCM. La nouvelle fonctionnalité est déjà disponible dans la CLI. Son déploiement sur le Web est en cours et elle sera bientôt activée par défaut pour toutes les organisations.

De nombreux projets Node.js s’appuient sur yarn.lock ou package-lock.json pour permettre aux développeurs de réinstaller les mêmes dépendances et de synchroniser leurs environnements, afin de faciliter le travail collaboratif.

Les fichiers lock sont extrêmement utiles, c’est indéniable : leur utilisation a explosé. Nous avons travaillé à améliorer leur prise en charge pour tous nos utilisateurs, afin de fournir des résultats de test encore plus précis et des performances bien plus rapides.

Pourquoi fallait-il améliorer la prise en charge des fichiers lock dans la CLI ?

Jusqu’à récemment, nous parcourions node_modules pour récupérer toutes les dépendances installées sur le disque. Cette méthode s’est révélée assez lente et parfois imprécise, car node_modules contenait souvent des dépendances supprimées depuis longtemps, qui n’étaient plus utilisées par le projet. Même si nous faisons de notre mieux pour tout maintenir à jour, il n’est tout simplement pas réaliste de toujours supprimer le dossier node_modules et de tout réinstaller depuis zéro pour s’assurer que seuls les packages réellement utilisés par le projet sont présents.

Nous rêvions d’un monde où l’utilisateur n’aurait pas besoin d’installer ses packages pour que nous puissions lancer un test. Après avoir étudié la question, nous avons créé une toute nouvelle bibliothèque node-lockfile-parser, capable de parcourir directement le fichier lock et le fichier package.json, plutôt que l’intégralité du dossier node_modules. Résultat : des performances et une précision nettement améliorées, disponibles dès aujourd’hui.

Si un fichier yarn.lock ou package-json.lock est présent dans un projet, nous le détectons automatiquement et traitons le projet comme étant basé sur un fichier lock. Pour les projets qui n’en ont pas, la prise en charge existante reste inchangée.

Remarque :

• snyk patch et wizard nécessitent toujours la présence du dossier node_modules, car nous devons appliquer les correctifs directement dans les dossiers des packages installés.

• Pour les projets Yarn utilisant une version de Node antérieure à la version 6, nous continuerons également à parcourir node_module. En effet, la bibliothèque Yarn utilisée pour analyser le fichier lock ne prend pas en charge les versions de Node antérieures à la version 6.

Quel impact cela a-t-il sur mes projets Web ?

Lors de l’importation d’un projet depuis GitHub, GitLab ou Bitbucket, nous nous appuyions auparavant uniquement sur le fichier package.json pour déterminer ses dépendances. Nous devions donc supposer quelle était la version exacte de chaque package installé sur le disque, en partant toujours du meilleur scénario (autrement dit, la dernière version de chaque package compatible avec la plage semver définie dans le fichier package.json).

Grâce à la prise en charge des fichiers lock, nous pouvons désormais fournir des résultats de test plus précis. Aujourd’hui, un test Snyk construit un arbre à partir des versions exactes résolues pour chaque package du fichier lock. Nous pouvons ainsi détecter des vulnérabilités qui n’avaient pas été signalées auparavant lors du prochain test Snyk. Mais pas d’inquiétude : si le paramètre de PR/MR de correction automatique est activé, les mises à niveau seront effectuées comme d’habitude et vous recevrez des notifications indiquant d’autres façons de traiter ces vulnérabilités signalées.

Snyk va-t-il régénérer les fichiers lock de mon projet ?

Pas encore. Nous travaillons activement à proposer cette fonctionnalité pour les projets Yarn et npm. La tâche est complexe, car la logique interne de résolution des packages de Yarn et de npm diffère considérablement, tout comme leurs fichiers lock.

D’ici là, toutes les pull requests nécessiteront une intervention manuelle, comme aujourd’hui. Ainsi, pour tout projet contenant des fichiers yarn.lock et package-lock.json, vous devrez mettre à jour le fichier lock avant de fusionner la pull request si le fichier package.json a été modifié.