JavaScriptのロックファイルを使用するプロジェクト向けに、テストを高速化・改善

ここ数か月、CLIとSCMインテグレーションの両方でロックファイルのサポートを改善するために取り組んできました。新機能はすでにCLIで利用可能で、Webでは段階的にリリース中です。まもなく、すべての組織でデフォルトで有効になります。

多くのNode.jsプロジェクトでは、yarn.lockまたはpackage-lock.jsonを使って、開発者が同じ条件でインストールを再現できるようにし、環境を同期して共同開発を円滑に進めています。

ロックファイルが非常に便利で、その利用が急増していることは間違いありません。より正確なテスト結果と、これまで以上の高速なパフォーマンスを実現するため、すべてのユーザーを対象にロックファイルのサポート改善に取り組んできました。

CLIでロックファイルのサポートを強化する必要があったのはなぜでしょうか？

これまでは、ディスクにインストールされたすべての依存関係を検出するために、node_modulesをたどっていました。この方法はかなり遅く、ときには正確さにも欠けていました。node_modulesには、プロジェクトで使われなくなってから長い依存関係が残っていることがよくあったためです。すべてを最新の状態に保つよう努めていても、実際にプロジェクトで使われているパッケージだけを確実に残すため、常にnode_modulesフォルダを削除して一からインストールし直すのは現実的ではありません。

ユーザーがテストを実行するためにパッケージをインストールする必要のない世界を目指しました。計画を重ねた結果、フォルダ全体ではなく、ロックファイルとpackage.jsonファイルを解析できる新しいnode-lockfile-parserライブラリを作成しました。これにより、現在ではパフォーマンスと精度が大幅に向上しています。対象となるフォルダはnode_modulesです。

プロジェクトにyarn.lockまたはpackage-json.lockファイルがある場合、自動的に検出し、ロックファイルを使用するプロジェクトとして処理します。ロックファイルがないプロジェクトは、これまでと同じ方法でサポートされます。

注:

• snyk patchとwizardでは、インストール済みパッケージのフォルダに直接パッチを適用する必要があるため、引き続きnode_modulesフォルダが必要です。

• Nodeのバージョンが6未満のYarnプロジェクトでは、引き続きnode_moduleの解析にフォールバックします。これは、ロックファイルの解析に使用するYarnライブラリが、Node 6未満のバージョンに対応していないためです。

Web上のプロジェクトにはどのような影響がありますか？

これまで、Github、GitLab、Bitbucket経由でプロジェクトをインポートする際は、package.jsonファイルだけをもとに依存関係を判断していました。そのため、ディスクにインストールされている各パッケージの正確なバージョンを推測する必要があり、常に最適なバージョン、つまりpackage.jsonファイルで定義されたsemverの範囲を満たす最新バージョンが使われていると仮定していました。

ロックファイルのサポートが加わったことで、テスト結果の精度が向上しました。現在のSnykテストでは、ロックファイルに記載された各パッケージの正確な解決済みバージョンに基づいて依存関係ツリーを構築します。そのため、次回のSnykテストで、これまで報告されていなかった脆弱性が検出される場合があります。ただし、ご安心ください。autofix PR/MRの設定が有効になっていれば、通常どおりアップグレードされ、報告された脆弱性へのその他の対処方法についても通知されます。

Snykはプロジェクトのロックファイルを再生成しますか？

まだ対応していません。現在、Yarnおよびnpmプロジェクトでこの機能を提供できるよう取り組んでいます。Yarnとnpmでは内部のパッケージ解決ロジックが大きく異なり、ロックファイルにも違いがあるため、簡単ではありません。

それまでは、現在と同様に、すべてのPull Requestで手動の対応が必要です。yarn.lockおよびpackage-lock.jsonファイルを含むプロジェクトでは、package.jsonに変更があった場合、Pull Requestをマージする前にロックファイルを更新する必要があります。