【问题标题】: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 文件应该共享相同的版本,还是分开进行版本化?

【问题讨论】:

    标签: npm versioning package.json semantic-versioning


    【解决方案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 - 这应该存在,与软件工程基础教科书中所写的完全一样。感谢您的洞察力。
    猜你喜欢
    • 2017-11-25
    • 2011-08-18
    • 1970-01-01
    • 2011-01-31
    • 2012-05-26
    • 1970-01-01
    • 1970-01-01
    • 2012-09-13
    • 1970-01-01
    相关资源
    最近更新 更多