最近，我正在研究反应原生项目。我做了一个旧项目，我想把它克隆到一个新项目中，这样我就可以在旧版本之上开发新东西，但不会影响旧项目本身。
我想到的是，每次使用相同的package.json npm install时，安装的node_modules文件夹可能都不一样。这可能是因为我们在某些模块的版本前面有前缀^或~。此外，安装的模块也有自己的依赖项，可以自行更新。
因此，它涉及到这个问题。我应该使用package.json来进行版本控制吗？
根据这里：Why do we need to use package.json?，它说package.json provides a simple way for people to keep track of packages they use in their application.
但是，如果package.json始终自行更新项目而不考虑不同模块的兼容性，如何使用我的项目进行版本控制。
我想到的唯一解决方案是：我们应该对node_modules进行版本控制。如果是这种情况，package.json变得毫无意义吗？
那么，我想知道在node_modules和package.json相关项目上进行版本控制的工业实践是什么？
答案 0 :(得分：3)
如果您使用的是5之前的NPM版本，那么您应该查看NPM Shrinkwrap。这会锁定您当前使用的NPM模块的版本。一旦提交给项目，如果其他人npm install他们得到了收缩包装中指定的确切版本。
<强> NPM-拆封
锁定发布的依赖性版本
发布NPM 5时，默认情况下运行package-lock.json时，它会自动创建一个类似于shrinkwrap的npm install文件。您应该将锁或shinkwrap文件提交到SCM。
您还应该查看Yarn。 Yarn开箱即用，带有yarn.lock文件，其工作方式相同，但具有更高的性能和离线功能。
使用详细但简洁的锁文件格式和安装的确定性算法，Yarn能够保证在一个系统上运行的安装在任何其他系统上的工作方式完全相同。
如果您已经有一个项目和node_modules文件夹，并希望在不重新安装所有模块的情况下更改为Yarn，那么您可以运行yarn import，这将生成基于您当前节点模块的锁定文件文件夹。
上述两种解决方案都意味着您不应该要求将node_modules添加到SCM中 - 这样做会在不同平台（Windows，Mac等）上的用户正在处理项目时添加其他复杂性。锁文件应该与您的项目一起提交。