Auto: 1 个 repo 中的多个包管理器插件

再考虑一下，我可能会更有意义地引入一个新的顶级配置选项。

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

为了实现这一点，我认为我们可以使用迭代器函数在多个事物上运行shipit并生成相同数量的提交

最新的前：

1. 同时运行
2. 在提交变更日志之前产生
3. 一次性提交所有变更日志
4. 产量直到版本碰撞
5. 如有必要，提交版本
6. 跑到最后

有了这个设置，你真的可以一起跳过 lerna

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

如果没有与package匹配的提交，则不会进行发布。 这以更简单的方式实现了独立的 monorepo 管理，并且没有lerna 。 如果你想要一个固定版本的 monorepo 走经典路线就是这样。

另一个很酷的功能是，您的仓库中可以有两个leran项目，它们具有不同的版本控制方案（ fixed和independent ）

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

这意味着您可以在一个 repo 中使用 chrome-web-store 插件和 npm 插件。

我假设你的意思是你_不能_在同一个项目中使用两者？

每个插件当前都提交、标记和推送。 这会产生很大的噪音。 可能必须将这些 git 操作移到核心，以便它只发生一次？ 尽管您可能需要为每个包单独提交。

采用混合方法可能是有意义的。 也许每个插件都会提交，但我们只推送一次？

我不太确定标签在每个文件夹都是它自己的打包版本的世界中如何工作。 您是否为您制作的每个版本创建了一个标签？ 你最后做一个吗？

再考虑一下，我可能会更有意义地引入一个新的顶级配置选项。

我喜欢能够自定义每个包的发布体验的想法。 绝对可以看到能够管理docs包与您的库包的 s3/gh-pages 部署的一些好处。

需要处理的一件事是在 1 个以上的发布管道中包含一个包。 在以下情况下会发生什么：

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

chrome-ext包是否同时发布到npm _and_ webstore ？ 还是npm发行版获胜是因为它是第一个声明的？

我不太确定标签在每个文件夹都是它自己的打包版本的世界中如何工作。 您是否为您制作的每个版本创建了一个标签？ 你最后做一个吗？

我认为我们可以匹配 lerna 行为。 一次提交只有很多标签。 每个标签然后成为它自己的版本

chrome-ext 包是否同时发布到 npm 和 webstore？ 还是 npm 版本获胜是因为它首先被声明？

在这种情况下，是的，它会尝试同时进行。 但这只是糟糕的配置。 您可以将其用作功能并说将包发布到两个不同的注册表（例如：npm 和 github 包注册表）

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

这听起来很有趣……而且很复杂😅

我通常 👍 拥有配置而不是试图在检测方面过于智能（因为这可能会以意想不到的方式分解并且难以测试）。

我想我的第一个问题是它的默认状态是什么样的。 如果您只有一个npm插件，是否需要添加配置才能使用？ 与其他人同样的问题。

至于 git 交互，在我看来，git 交互通常应该只是插件管道的一部分。 如果插件需要进行提交，它应该能够接入一个可提交的钩子。 推送可能应该只在核心处理，因为它对 CI 的运行方式有影响。

如果你只有一个 npm 插件，你需要添加配置才能工作吗？

今天有效的配置应该适用于packages世界。 所以不需要改变。 大多数重大更改都是节点 API 方面的，对普通用户不可见。

如果插件需要进行提交，它应该能够接入一个可提交的钩子。

我喜欢这个主意。 在 auto 中形式化这种 git 交互可能很有用。 如果他们不使用这个钩子，那只会意味着更多的噪音（例如：额外的提交和额外的推送）

我也在考虑如何将 Auto 与 monorepo 一起使用，并提出了一种可能适合您需要的略有不同的方法。

基本上，如果你有一个 monorepo，你可以有多个子目录，每个子目录都有自己的.autorc文件，可以设置每个子项目需要的任何插件。

然后，您可以为每个项目选择不同的前缀，以便在需要时可以在不同时间发布每个项目。 例如，子项目 1 的发布可以用sub-project/v1.4.5标记，另一个项目将获得标记sub-project2/v9.9.9

Auto 然后可以使用类似git describe --tags --matches "sub-project1/*"来相应地获取和更新每个项目的标签。

只是一个想法。

这实际上与我一直采用的方法非常接近。 我有
这周一直在努力。

到目前为止，我不得不将该标志添加到某些命令中（-匹配）和
它进行得很顺利。

我已经采用了“包”字段方法，它基本上只是
“autorc”数组

为了获得前缀，我为插件添加了一个钩子以提供名称。 这个
如果插件是多包兼容的，也将有助于向 auto 发出信号

2020 年 1 月 29 日星期三晚上 9:11 亚历杭德罗·巴里恩托斯 <
[email protected]> 写道：

我也在考虑如何将 Auto 与 monorepo 一起使用并想出了
一种稍微不同的方法，可能适合您的需要。

基本上如果你有一个 monorepo 你可以有多个子目录
每个都有自己的 .autorc 文件，可以设置任何插件
每个子项目都需要。

然后，您可以为每个项目选择不同的前缀，以便
如果需要，每个项目可以在不同时间发布。 例如一个
sub-project1 的发布可以标记为 sub-project/v1.4.5 和
另一个项目将获得标签 sub-project2/v9.9.9

Auto 然后可以使用类似 git describe --tags --matches 的东西
“sub-project1/*”相应地获取和更新每个项目的标签。

只是一个想法。

—
您收到此消息是因为您创作了该线程。
直接回复本邮件，在GitHub上查看
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTLNW50WZHJKTLNWS50000000
或退订
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

回去再读一遍，我真的很兴奋！ 带有包名前缀的多个标签听起来非常好。 另外，我真的很喜欢packages字段。

@hipstersmoothie今天有没有一种简单的方法可以使用 Shipit 发布到 2 个 npm 注册表，你见过吗？ 或者我现在没有很好的概述的自动中的某些功能切换。

@vincentbriglia会发布到 GitHub 包的插件工作吗？ 它几乎可以搭载 npm 插件。 next和latest发布很容易，金丝雀没有多大意义。 想法？

@hipstersmoothie我们有一个案例，我们将相同的包发布到 NPM 注册表和 GHPR 注册表。 这里的原因是 GHPR，即使这样宣传，也不能正确代理包。 潜在的问题是我们在 npm 和 github 上有相同的范围。

我们主要是闭门开发，我们使用金丝雀版本与我们的设计团队从feature branches > next进行对话/批准，因此金丝雀版本在这种情况下仍然对我们有用。 npm 插件目前提供了这个功能，所以失去它会很遗憾。

我想使用 GHPR 的上下文通常是它是在私有“组织”上下文中发布的主要位置，如果要公开一个组件，npmjs.org 是次要的。 （我还没有看到有人从 github 安装公共组件）。 在开源上下文中，它通常是 npmjs，没有 GHPR 或其他私有包注册表。

附带说明一下，由于您提到了一个特定的 GHPR 插件：我们已经为下周留出了一些时间来创建一个自动插件，该插件将根据某些规则删除包版本（组织仅限于 50Gb 的包，其中包括 docker图片）

• 删除范围内的最后一个金丝雀
• 删除范围内的倒数第 n 个
• ...

我也很乐意和你一起创建一个特定的 ghpr 发布者，直到 v10 开始工作，这里提出的想法看起来非常令人兴奋，也许更“面向未来”。

我们暂时可以不同时发布公共和私有数据，但至少你知道这是我的用例。

我更多地考虑了“辅助包注册表”插件。 所以 npm 插件会像它一样工作，发布到任何配置的注册表。 然后这个新插件将发布到第二个注册表（无论是 npm 还是 ghpr 都无关紧要）发布 HEAD 提交中的任何版本。

附带说明一下，由于您提到了一个特定的 GHPR 插件：我们已经为下周留出了一些时间来创建一个自动插件，该插件将根据某些规则删除包版本（组织仅限于 50Gb 的包，其中包括 docker图片）

这似乎是一个很好的功能。 我不知道存在这些限制！

这个新插件将发布到第二个注册表（无论是 npm 还是 ghpr 都无关紧要）发布 HEAD 提交中的任何版本

那肯定会奏效！ 编辑：也适用于我们的场景

你好！ Auto 相对于该线程的当前状态是什么？ 是否可以从同一个版本中发布多个内容？

因为每个包管理器插件都依赖于包管理器的一些额外文件（除git-tag之外的所有文件）

我认为这是一个错误的假设。 docker插件依赖于任何文件吗？ 它可能是不必要的，所以也许这是一个坏例子。 这是另一个：我对使用 Auto 和sbt （Scala 最常见的构建工具）很感兴趣，它没有任何机器可读的 JSON/XML 配置。 一个 sbt 构建是用 Scala 代码配置的，为了提取有关构建的任何信息，您需要以某种方式与 sbt 通信。

这以更简单的方式完成了独立的 monorepo 管理

从这个线程看来，目标是容纳具有不同发布需求的多个子项目的 monorepo 项目。 产生不同类型工件的单个项目怎么样？ 例如一个 Docker 镜像和一个配置档案（要上传到某个地方）。 或者 GitHub 操作，它可以作为库发布到 NPM，也可以作为 GitHub Releases 上的操作发布。

每个插件当前都提交、标记和推送。 这会产生很大的噪音。 可能必须将这些 git 操作移到核心，以便它只发生一次？ 尽管您可能_想要_为每个package单独提交。

我认为这是当前插件实现的主要问题。 这又回到了我对每个命令“只做一件事非常好”的说法的publish钩子应该真正_only 发布_ 给定的包管理器，而不是创建提交或推送 git 标签。 如果每个发布插件只能专注于其包管理器细节的实现，则可以重用和/或共享流程的公共部分。 是否仍然可以通过 Auto 实现这一目标，还是过于偏向于类似 NPM 的项目？