Npm 在包含多个包的回购协议中，每个包的版本应代表什么？

我正在开发一个web应用程序，其中React

客户端

应用程序和Node Express

服务器

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

看起来，这些独立的包是系统（即web应用程序）的子模块。例如，考虑路由处理方式，其中服务器不识别的任何请求由<代码>客户端< /代码>路由器处理：

// 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

文件应该共享相同的版本，还是单独进行版本控制？

每个包都应该单独进行版本控制。将它们绑定到相同的版本号意味着一个简单的bug修复，另一个则需要无意义的版本升级。不要对你的顾客撒谎！软件包版本号适用于其内容，且仅适用于其内容。即使是包的包也应该有自己的版本序列

---

或者，您可以只发送一个包。

我想我已经看到了它的价值-例如，如果我在将来为一个新的Vue或FooX.js删除React客户端，那么在客户端语义发生更改时，服务器API仍然存在。此外，还可以添加另一个客户机（如移动客户机）或服务器操作/物流可以更改，这样客户机就不能再从同一个域提供服务，从而进一步解耦这两个包。我解释的方向对吗？听起来不错。理解版本控制的关键是准确地理解您使用该数字跟踪的内容。在实践中，含有大量位的大型单片封装相当脆弱。在一个大多数客户都不曾使用的角落里修复一些客户关键的bug，最终迫使所有人都来安装整个东西。但是，有时您需要打包一组包（当然每个包都有单独的版本），所以您可以说这里有一个我们测试并提供完全支持的版本集。

但是，有时您需要打包一组包（当然每个包都有单独的版本），所以你可以说这是我们测试过的一个版本集，它提供了对

的全面支持——这应该存在于《软件工程基础》教科书中。谢谢你的洞察力。