Auto: 使用 npm 作为真实的版本来源

哦，我喜欢那个。 不过这对于 monorepos 来说可能会很棘手

由于我们为 lerna 做--force-publish=* ，所以它不应该是一个问题，因为所有的包都应该有一个链接的版本。

将来，如果我们删除该标志，我们将不得不... idk

此外，我们只运行npm version ，它只需要一个 semver 字符串。 我们现在实际上并没有在任何地方设置包裹编号。 自己设置并不难，但 monorepos 似乎又不简单

大多数命令也适用于标签，因此如果发布未标记可能会导致一些问题。

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

“我越来越相信‘独立’版本控制模式是一个错误。它所做的只是让人们将随机包扔到一个存储库中，然后在他们必须同时对它们进行版本控制时抱怨。” ~ 来自 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版本我想我们会没事的。 PR 查找将计算一个新的 semver 凹凸并将其应用于当前分支中的版本。

如果我们将其更改为使用 git 树之外的某些内容，我认为我们将无法支持该行为，因为 npm 上只有 1 latest （或我们从中获取最新版本的任何地方）

这似乎是一个很好的功能。 可能需要一些工作来实施。

版本：

• 我们使用最新版本计算version - 这可以轻松切换到软件包版本吗？
• github 上的最新版本可能有问题。 我认为您实际上无法以编程方式设置“最新版本”。 因此，当发布 1.x 补丁时，它将成为最新版本。

发布/变更日志

• getCurrentVersion返回 lastRelease 如果 gt(lastRelease, lastVersion) - 所以这也需要意识到这一点

这意味着我们已经在使用 git 树之外的东西了，对吧？

我们需要依赖 latestRelease 来确保它有一个与之关联的 git 标签，所以切换不是一个选项，因为我们不能确定最新的 npm 版本有一个标签（就像这个问题描述的那样） .

我认为我们可能需要一个从最后一个 git 标签版本的新标志。 --from-git

有了这个，发布命令可能会起作用。 我们必须理清变更日志的样子。

--from-git标志也可以覆盖查看 NPM 的任何内容。 我认为这意味着我们可以合并 #173