Auto: 信頼できる唯一の情報源としてnpmを使用する

ああ、私はそれが好きです。 ただし、これはモノリポジトリでは扱いにくい場合があります

lernaに対して--force-publish=*を実行するので、すべてのパッケージにリンクされたバージョンが必要なので、問題になることはありません。

将来、そのフラグを削除した場合、次のことを行う必要があります... idk

また、semver文字列のみを受け取るnpm versionを実行するだけです。 現在、実際にはどこにもパッケージ番号を設定していません。 自分で設定するのは難しいことではありませんが、monoreposは単純ではないようです。

ほとんどのコマンドはタグでも機能するため、リリースにタグが付けられていないと、問題が発生する可能性があります。

https://github.com/azu/can-npm-publish

「「独立した」バージョン管理モードは間違いだとますます確信しています。それは、ランダムなパッケージを1つのリポジトリにスローし、同時にバージョン管理する必要があるときに文句を言うだけです。」 〜lernaメンテナから。

したがって、 --force-publish=*は問題ないようです。

--force-publishと独立したバージョン管理は同じものではありません。
デフォルトでは、lernaはパッケージに変更が加えられた場合にのみ更新を公開します。 --force-publish=*を使用すると、前回の公開以降に変更がない場合でも、lernaにすべてのパッケージのバージョンを公開するように強制します。

つまり、パッケージAは変更がありますが、 Bは変更がありません。 lernaはA新しいバージョンのみを公開します（ Bは現在のバージョンのままになります）。 次のリリースAとBは変更があり、どちらも同じ新しいバージョンで公開されます。

私が考えていたもの（そしてこれが私たちがサポートするものであるかどうかはわかりません）は、 master （またはメインブランチ）ではないリリースの可能性です。 この時点まで、リリースには1つのパスがあると常に想定しており、それらは常に線形です（npmまたはgithubのlatestバージョンを使用）。

以前のリリースにパッチを適用する必要がある場合はどうなりますか？ （1.xにはバグがあり、 masterは2.xにありますが、1.xw /修正もパッチしたいです） lernaまたはpkgから外れる場合

gitツリー以外のものを使用するようにこれを変更した場合、npm（または最新バージョンを取得する場所）にはlatest 1つしかないため、その動作をサポートできないと思います。

それは良い機能のようです。 実装には多少の作業が必要になる場合があります。

バージョン：

• 最新のリリースを使用してversionを計算します-これはパッケージバージョンに簡単に切り替えることができますか？
• githubの最新リリースが問題になる可能性があります。 実際にプログラムで「最新リリース」を設定することはできないと思います。 したがって、1.xにパッチを公開すると、最新のリリースになります。

リリース/変更ログ

• getCurrentVersionは、gt（lastRelease、lastVersion）の場合、lastReleaseを返します-したがって、これもそれを認識する必要があります

これは、すでにgitツリー以外のものを使用していることを意味しますよね？

gitタグが関連付けられていることを確認するためにlatestReleaseに依存する必要があるため、最新のnpmバージョンにタグがあるかどうかを確認できないため（この問題で説明されているように）、切り替えはオプションではありません。 。

おそらく、最後のgitタグからバージョンを変更する新しいフラグが必要になると思います。 --from-git

これで、releaseコマンドはおそらく機能します。 変更ログがどのように見えるかを整理する必要があります。

--from-gitフラグは、NPMの検索をオーバーライドすることもできます。 ＃173をマージできるということだと思います