継続的インテグレーション (CI) 環境にビルドしてデプロイし、開発、ステージング、ライブに自動デプロイするビルド サーバーがあります - すべて TFS ビルド定義を使用します。
ビルド サーバーでは、Dust でダウンロードしたユーティリティ (dustc) を使用して、(デプロイ手順の前に) Dust テンプレートをコンパイルする必要があります。Visual Studio 内でローカルに実行すると、Visual Studio (VS) がフォルダー node_modules に開始されると、Dust がダウンロードされますが、このフォルダーは通常チェックインされません (そうしないと、多数のクライアント側ライブラリとバージョンがすぐに管理オーバーヘッドになります)。
Dust は npm 経由でダウンロードされます (私は v3.5.2 を使用しています)。私が理解しているように、npm を使用してダウンロードするモジュールをダウンロードする標準的な方法は次のとおりです。
- ローカルに (VS 内で) NuGet 経由で npm をダウンロードします。これにより、プロジェクトに含まれてチェックインされた npm.cmd を含むプロジェクト (".bin") のルートにフォルダーが作成されます。
- 次に、ソリューション/プロジェクトの成果物がダウンロードされた後のビルド サーバーで、NuGet パッケージがダウンロードされます (npm を含む)。
最後に、次のコマンドを送信します (この場合、VS ビルド後のタスクに含まれていますが、NuGet パッケージがダウンロードされた後であれば、すべて問題ありません)。
cd "$(ProjectDir)" call "$(ProjectDir)\.bin\npm.cmd" install dustjs-linkedin --save-dev
最終結果は、Dust がプロジェクト構造 (node_modules フォルダー内) にダウンロードされ、Dust テンプレートをコンパイルするコマンドを発行できるようになるはずです。
ただし、問題は npm が NuGet 経由でダウンロードされた場合、npm フォルダー構造が大量にネストされているため、Windows パスの 260 文字の制限を超えていることです ( https://github.com/nodejs/node-v0.x-archive/issues/6960 ) - その結果、ジョブが npm を実行して Dust をダウンロードする前に、ビルドが失敗します (注: TFS フォルダーの長さを短くしましたが、npm はビルド名、プロジェクトなどを分割する余地がほとんどありません。たとえば、 .../packages/Npm.3.5.2/node_modules/npm/node_modules/npm-install-checks/node_modules/npmlog/node_modules/are-we-there-yet/node_modules/readable-stream/node_modules/core-util -is/lib は約 170 文字です)
Node npm windows file paths are too long to install packagesを読んだことがありますが、verion 3.x の使用、または npm-flatten/dedupe の使用を示唆していますが、まだ問題があります - 主に失敗するのは NuGet ステップであるためです - npmで何でもできるようになる前に
解決策は、必要なファイルのみを選択することです (つまり、npm から、またはおそらくより簡単な [しかし柔軟性が劣る] ダスト ファイル [dustc など] のみ) をソース管理に含め、NuGet には npm を含めません。しかし、これは厄介です。チェックインしたファイルが更新された場合 (よくあることですが)、すべてがそのままで実行されていることを確認する必要があります。
よりクリーンな方法はありますか？
