なぜこれを行う必要があるのか​​疑問に思っています。 これで解決している痛みはありますか？ 私が見る限り、私たちが持っているツールは現在機能しています。 すべてのツールをnrwlプラグインに書き換えると、どのようなメリットがありますか？

書き直しではありません–それはnxワークスペースに統合される方法です。 ライブラリをプラグインに変換する必要があります。 そうすれば、私たち自身のビルダーがどのように構築されているかという「ハッキー」な方法を取り除くことができます。
たとえばtsc --outdir /node_modules/dynatrace/barista-buildersで

nxのガイドラインに従う必要があります。これは、意見の分かれるフォルダー構造であるため、そうでない場合、ツールが期待どおりに機能しないためです。

ここで間違っている場合は訂正してください。ただし、現在、ツールは期待どおりに機能しますね。

ではない。 依存関係グラフをクラッシュさせるツールからファイルがリントおよびインポートされないという問題が発生します。 私たちのツールはライブラリではありませんが、nrwl / nxの意味でのツールではありません。 これらはプラグインなので、1つとして扱う必要があります。 これは、 @ ffriedl89ワークスペースのリファクタリング後に取り組む必要があります。

じゃあオーケー。 @ ffriedl89が私に与えた説明を理解したので：

• nxの境界リンティングルールにappsとlibsパスがハードコードされているため、すべてのツールを＃570のlibsフォルダーに移動する必要がありました。
• ツールをlibに移動したため、nxの他のリンティングルールは失敗します。これは、libraryRoot内の追加ファイル（つまり、Dockerfileなど、一部のツールの場所で依存するファイル）が許可されていないためです。
• Nxは、追加のツールが必要であることに明らかに気付いたため、バージョン9でこれらの新しいソリューションを提供します。 そして、これを行う方法は、ツール（ライブラリと見なすべきではありません）を、リンティングがそれほど厳密ではないプラグインフォルダーに追加することです。

@tomheller完璧な要約：D

この問題は30日間開いており、アクティビティがないため、古くなっています。 古いラベルやコメントを削除しないと、5日で閉鎖されます

この問題は90日間開いており、アクティビティがないため、古くなっています。 古いラベルやコメントを削除しないと、5日で閉鎖されます