Handlebars.js: 4.xのNode.jsバージョン要件は何ですか？

@ ErisDShey👋私はyargs @ 15.xxにはノード6が必要なので、一部のハンドルバーユーザー（エンジンフィールドに基づく）では壊れている可能性があります。

〜yargs @ 15は

ハンドルバーのバージョンサポートの目標は何ですか。少し古いバージョンのyargsをターゲットにするためにあなたと協力することができます（ただし、0.4までさかのぼってサポートすることはできません）。

これを人々にとって大きな変化と呼びたくなるかもしれません。

この場合に失敗するはずのテストが実際にありますが、Travisログに隠されたエラーメッセージが表示されていても、ビルド自体は失敗しませんでした。

テストでは、0.10から始まるノードバージョンでハンドルバーCLIを使用しようとします。

@ErisDS私はこれが来るのを見ませんでした。 元に戻しましょうか。

@nknapp @ErisDS元に戻さないと、元に戻してエンジンを更新してmajorした場合は、かなり混乱する可能性があると思います。

脆弱性がなく、ノード6へのサポートをサポートするyargs@14をインストールできます。ただし、ノード6と8はどちらもEOLであり、パッチは適用されなくなります。 だから私はあなたのバージョンサポートの目標が何であるかについていくつかの考えを入れます（0.4はかなりの作業なしでオプティミストまたはヤーグのパッチを当てられたバージョンによってターゲットにされることができる可能性は低いです）。

@ ErisDS ＃1669の統合テストを修正しました。 レビューしますか？

@dougwilsonこれを私たちの注意を引いてくれてありがとう❤️私たちがよりよく理解するために、Node v6に対してどこで、なぜ実行しているのか説明していただけますか？

私と@nknappはチャットをしていて、十分なメンテナがいないため、Handlebarsの広範なノード互換性を終了する時が

今日は、互換性を更新して、現時点ではNode.jsv6を最小限に抑えます。

また、私はテストを修正するためにV14とマージ@nknappへの変更をyargsをダウングレードします。

これにより、実用的でありながら非常に広範囲のノードバージョンをサポートし、ミニマストの問題が発生しない動作バージョンが得られるはずです。

コミュニティからのフィードバックに基づいて、v6とv8を短期間サポートし、快適なものを社内で削除するための戦略とタイムラインを決定します。

@bcoe yargs v14で引き続きサポートするために、追加の作業を行うことは期待できません。 本日ここにご来場いただき、会話に参加し、yargs v14が機能し、安全であることを明確にしていただき、誠にありがとうございます。 とても助かりました❤️

また、ノードv6で問題が発生しているため、ここに来ました。

[email protected]
└─┬│ [email protected]
└─┬│ [email protected]
│└──[email protected]

@ErisDSを提案しているソリューションをありがとう、それは私たちにも

ここで説明する変更は、4.7.5で行われ、出荷されています。 Node.jsサポートは4.xではv6 +に設定され、yargsはv14に固定されています。

まだ使っていますか

この変更の考え方は、v10 +に直接移行するのではなく、制約内で現実的な互換性を提供するのに十分なはずであるということです。

私はメジャーリリースを行わないように指示されているので、他の誰かが明るい考えを持っていない限り、これであるか、安全でない依存関係を持つことに戻ります。

@dougwilson私はそれに全く同情していません。 これがあなたに多くの苦痛を引き起こしたことを心からお詫び申し上げます。

最終的に、この新しいセキュリティレポートツールはすべて優れていますが、間違いなく圧倒的です。 私が維持しているほとんどすべてのソフトウェアには、主に誰にも影響を与えない開発者の依存関係のために、複数のフラグがあります。 ここで行われたように、依存関係を交換するために何ヶ月もの作業が必要であり、この場合、作業が私たちのために行われたことに非常に感謝しています。 だから私たちの痛みは同じ場所から来ていると思います...

このモジュールでは、岩と固い場所の間に立ち往生しています。 npm auditでビルドが失敗している人を支持しますか、それとも（非常に）古いソフトウェアの互換性を削除して監査の問題を修正したためにビルドが失敗している人を支持しますか？

また、あなたの言っていることから、v6のサポートで十分だと理解しました。 繰り返しになりますが、あなたの場合はそれだけでは不十分であると申し訳ありません。 私が言ったように、私は何をすべきかについての考えがかなりありません。

@ErisDSここであなたのハードワークに感謝します❤️

私は@dougwilsonに同意する傾向があります。これは、エンジンフィールドを更新する明示的なコミット（5.xとしてリリースする価値があると思われます。

あなたがコミュニティのためにやっている努力に心から感謝します。

また、ここのスレッドに基づいて今日の変更を行ったことを明確にしておきます。v6は、発言したすべての人にとって十分であると信じていました。 ですから、私は今、同情的ではないと呼ばれていることに少し憤慨しています。

EOLから2年以上経過したバージョンのノードを削除するための大きなバンプを提唱することは困難です。 それは、それが耳障りで、人々のために多くの仕事をしていることに感謝しないということではありません、私はそうします。

yargをさらにダウングレードするか、別の依存関係を使用することですべての問題が解決する可能性がありますが、私にはtest + merge + releaseの容量しかありません。

しかし、そのようなことに時間を費やすことは、実際の仕事を別の日に延期するだけだと思います。 より悪いセキュリティの脆弱性が発生した場合、同じことが再び発生する可能性があります。

これについて話し合い、Node.js LTSと現在のバージョンを一般的にサポートしたいと考えており、古いNode.jsバージョンを削除することは重大な変更と見なされるべきではないことに同意しました。

問題を提起するのは良かったと思います（しかし、誤解のために余分な仕事をしたのは私ではなかったので、ここでは自分自身のために話しているだけです）。 しかし、このトピックはとにかくある時点で取り上げられたはずであり、少なくとも今、私たちはこれに対して共通の見解を持っています。 ＃1671がマージされるときに、READMEにも文書化されます。

したがって、解決策があなたが望んでいたものでなくても、それからいくつかの良いものが生まれました。

@dougwilson問題を提起したことをお詫びする必要はありません！

@nknappが指摘したように、あなたがそれを提起していなかったら、私たちは私たちの方針を明確にしなかっただろう。 うまくいけば、ポリシーを明確にすることで、あなたのような将来の人がフラストレーションを避けるのに役立つでしょう。

真剣に、あなたの現実世界の痛みを引き起こし、私たちがそれを乗り越えるのを手伝ってくれてありがとう。

サポートされているNode.jsランタイムのバンプを、重大な変更以外のものとして扱うことはお勧めしません。 FWIW、Node.jsはこれを行いません。

会話は@dougwilsonが彼のメッセージを削除するので、今混乱少しですが、私はまた、両方にできないことはせずに、バージョンに依存関係をバンプすることを追加したいminimist CVEとノードバージョンのサポートに関してsemver維持でこのパッケージの問題ではありません。 minimist depのレポートに問題があります。 重要な依存関係がsemverを適切に追跡する能力を壊すことをめぐって、そのCVEの削除のために戦う必要があります。

編集：ここで私の意見を明確にするために、私はCVEに関する報告をやめることを意味します。 Dougのような人々にプロジェクトで除外を使用することを推奨する場合、またはnpm監査結果から除外を削除できる場合は、先に進んで、この主要な行で古いノードバージョンのサポートを維持してください。 私は、問題がライブラリでパッチされるべきであることを否定しようとはしていません。ただ、ここでの報告が良いよりも害をもたらすということだけです。

この問題を適切に検討することは少し不可能ですが、会話からは、 minimist大失敗に起因する問題と、サポートするNode.js LTSバージョンを特定することの組み合わせであるように見えますか？

正直なところ、この時点で、 minimistのCVEが改訂され、取り消されることを非常に嬉しく思います。 とは言うものの、

ミニミストのCVEは非常に破壊的です。 それは、私が維持しているほぼすべてのパッケージにフラグを立てていますが、（これまでの私の知る限りでは）それらのいずれでも悪用可能ではありません。

正直なところ、この時点で、ミニミストのCVEが復活し、取り消されることを非常に嬉しく思います。

これは本当の可能性ですか？

わからない。 調べる価値があります。

@isaacsまたは@darcyclarke 、ここでレジストリレポート側でできることはありますか？ 実際のCVEを取り消すことはオプションではないと仮定すると（おそらく有効であるため）、 npm auditでの報告を停止できますか？ これで修正できることは解決されたようですが、これについて報告し続けることは不必要な苦痛を引き起こしているだけです。

@wesleytodd今日の午後2時（東部標準時）に「解決策」について「 OpenRFC-DeepDive 」の呼び出しがキューに入れられました。 会話は、監査通知の解決/無視をサポートピア/非公開部門の解決というより広範なトピックに触れることになると思います。 興味がある場合、またはただ座ってみたい場合は、電話に参加することをお勧めします。

ただし、具体的に質問に戻りますが、有効なCVEを取り消すためにレジストリ側で行うことはないと思います。 繰り返しになりますが、より良い方法は、コミュニティ（特にメンテナ）が不要なノイズに対するdepの使用を無視/ホワイトリストに登録するためのメカニズムを提供することだと思います。

この特定のCVEは、ミニミストのmkdirp 0.5.1のdepがパッチが適用されていないバージョンに固定されており、mkdirpが非常に広く使用されているという事実と相まって、現在のnpm audit fix機能の欠点を浮き彫りにしました。問題を解決可能であると適切に診断します。 （この場合、 npm update mkdirp --depth=9999は、これまでに見たすべてのケースを修正します。）

幸いなことに、npm v7のnpm auditはこれを適切に診断します。したがって、npm v7のnpm audit fixは、このクラスのケースの状況を修正します。

これのもう1つの側面は、v6のnpm audit fixは、 package-lock.jsonまたはnpm-shrinkwrap.jsonファイルで定義されているネストされたメタ依存関係の問題を自動的に修正せず、元々トップレベルの部門を不適切に巻き込んだことです。修正を含むバージョン範囲でロードされた場合でも、それらのメタデップがロードされるようにトリガーしました。 したがって、 nycは、数レベルの深さで完全にアップグレード可能であるにもかかわらず、脆弱なバージョンのminimistに依存するのは間違っているように見えます。

私たちが検討していることの1つは、実際にmkdirp 0.4.1 - 0.5.1に対するアドバイザリを作成して、mkdirpのユーザーが更新できることを確認できるようにすることですが、これで問題が解決されるかどうかは完全には明らかではなく、この「メタアドバイザリ」を実装します。 「一般的に、レジストリの範囲と依存関係グラフの相互接続性を考えると、トリッキーで非常に時間がかかる可能性があります。 これにもっとエレガントに対処できる技術的な解決策があります。これは近い将来に検討する予定です。

これは現在消滅しており、＃1672を介してこのライブラリで修正されているため、ここでこれ以上の会話を控えることは問題ないようです。 将来的には、 npmの変更が、これをそれほど問題のないものにするのに役立つことを願っています。

@wesleytoddはここでの会話を完全に