在包含多个包的 repo 中，每个包的版本应该代表啥？

Posted 2023-03-07

【中文标题】在包含多个包的 repo 中，每个包的版本应该代表啥？

【英文标题】：In a repo containing multiple packages, what should the version of each represent?在包含多个包的 repo 中，每个包的版本应该代表什么？

【发布时间】：2018-08-13 05:03:17

【问题描述】：

我正在开发一个 Web 应用程序，其中 React client 应用程序和 Node Express server API 存在于同一个存储库中，但具有单独的 package.json 文件。结构如下：

root
-client/
  --src/     
  --package.json  // manages create-react-app dependencies, scripts
-controllers/
-models/
-routes/
-app.js
-package.json // manages node express server dependencies, scripts

看起来，这些单独的包是系统（即网络应用程序）的子模块。例如，考虑路由的处理方式，服务器无法识别的任何请求都由client 路由器处理：

// app.js

require('./routes/...')(app)      // api routes defined first

if (process.env.NODE_ENV === 'production') 
  app.use(express.static('client/build'))
  const path = require('path')
  app.get('*', (req, res) =>    // non match fall through to client
    res.sendFile(path.resolve(__dirname, 'client', 'build', 'index.html'))
  )

服务器 API 未启用 cors。

这些package.json 文件应该共享相同的版本，还是分开进行版本化？

【参考方案1】：

每个包都应该单独进行版本控制。将它们绑定到相同的版本号意味着一个简单的错误修复，需要另一个无意义的版本碰撞。不要欺骗你的客户！包版本号适用于其内容并且仅适用于其内容。即使是一个包的包也应该有自己的版本序列。

您也可以选择只运送一个包裹。

【讨论】：

我想我已经看到了它的价值——例如，如果我将来为新的 Vue 或 FooX.js 删除 React 客户端，则服务器 API 仍然存在，而客户端语义发生了变化。此外，可以添加另一个客户端（例如移动客户端）或服务器操作/物流可以更改，这样客户端就不能再从同一个域获得服务，从而进一步分离两个包。我是否朝着正确的方向解释了这一点？

听起来像。了解版本控制的关键是准确了解您使用该数字跟踪的内容。内部有很多位的大型单片封装在实践中相当脆弱。在您的大多数客户从未使用过的角落修复一些客户关键错误，您最终会迫使每个人都接受并安装整个东西。但是，有时你想打包一堆包（当然每个包都是单独版本的），所以你可以说这是我们测试并提供全面支持的版本集。

But then, sometimes you want to package a bunch of packages (each individually versioned of course), so you can say here's a version set we tested and provide full support for - 这应该存在，与软件工程基础教科书中所写的完全一样。感谢您的洞察力。