Auto: プラグイン：セマンティックリリーススタイルのコミットメッセージに基づいてPRラベルを適用します

それがESMにどのように依存するかはかなり奇妙です

おそらく、本番環境ではなく、ビルドにesmを使用しているはずです。

ビルドしてdistフォルダーを公開するのではなく、babel-registerを使用するようなものです。

最初は同じだと思いましたが、ソースコードを見るとそうではありません。

編集：ああnvm、あなたはesmが公開前にコンパイルするために使用できると言っています。 PRを送るべきです。

それ以外の点では、良いモジュールのように見えます。 素晴らしくて無駄のない

esmはコンパイル用に作成されていないようです： https ：//github.com/standard-things/esm/issues/13#issuecomment -321710199

今のところフォークして、 importとexportの構文をCommonJSに変換すると言います。

うーん、ええ、私はちょうどreadmeを読んでいました。 誤解したようです

esmは65kbを追加するようです😮

https://packagephobia.now.sh/result?p=parse-commit-message
https://bundlephobia.com/[email protected]

https://github.com/developit/microbundleに切り替えるためのPRを作成し、おそらく彼がそれを追加します。

代わりにhttps://github.com/egoist/biliの使用を検討する必要があり

https://github.com/tunnckoCoreLabs/parse-commit-message/pull/55

ところで、パーティーに参加します。 git-commits-sinceとdetect-next-versionはここでもっと役立つかもしれませんか？

esmを使用しているのは、保証とノードのesm機能フラグの背後にあるためです。 私は簡単にascjsまたはrewrite-importsのような同様のものを使用できますが、 esmはインポート/エクスポートだけではありません。 そして、私はビルドステップなどを何もしなかったので、テストのためにそれをランナーへのフックとして使用します。

これで、 ascjsまたはasbundleに切り替えることができます。

@aleclarsonなぜ私はサイズがそんなに問題なのですか？ ノードランドでも、パッケージマネージャーはすでに重複排除を行うのに十分なほど賢いです。

@aleclarsonなぜ私はサイズがそんなに問題なのですか？ ノードランドでも、パッケージマネージャーはすでに重複排除を行うのに十分なほど賢いです。

重複する依存関係について懸念事項として言及したことはありません。 私は一般的に肥大化したツールに警戒しています。 「軽いほど良い」というのが私の経験則ですが、それぞれが自分のものです。 私はこれについて議論することにあまり興味がありません。 :)

ところで、パーティーに参加します。 git-commits-sinceとdetect-next-versionはここでもっと役立つかもしれませんか？

これらのパッケージはauto-releaseにすでに存在するロジックを複製しているように見えるので、 parse-commit-messageを使用することをお勧めしますが、メンテナンスの負担を軽減するために、 @ hipstersmoothieが既存のロジックをこれらのパッケージに置き換える可能性があります。

：rocket：問題は10.0.0でリリースされました：rocket：