事情是这样的，今天上午，后端同学 clone 了我们的一个小程序项目，希望到自己的电脑上跑起来。
然而，令人尴尬的是，他在 npm install 之后，项目并没有如愿运行，并抛出一个大大的错误。
后来， 另一个前端同学灵机一动，将自己的 node_modules 拷给了他，小程序终于如愿在他电脑上跑了起来。此后我们群里有了下面的对话：
本人自认为脸皮还算不薄，但是说我们的 node_modules 是祖传的，确实令人难以招架。。痛定思痛，为了防止被后端同学，乃至以后新来的前端同学 diss，我决定好好研究一下 package.json 这个文件。
在讲解 package.json 之前，首先推荐阮老师的一篇文章，package.json 文件, 里面对需要了解的常用字段都有解释，比如 dependencies, devDependencies,scripts,main,version字段等，这里就不讲了。仅谈谈依赖的版本管理。
依赖的版本管理
如果一个项目做了不兼容的更改，并发布了一个大版本，你的项目依赖了他的库，安装完成之后，十有八九是要报错的。所以我们要在package.json中告诉npm只能装哪个版本，或者哪几个版本的库。规则如下（摘自上面的文章）：
指定版本：比如1.2.2，遵循“大版本.次要版本.小版本”的格式规定，安装时只安装指定版本。
波浪号（tilde ～）+指定版本：比如~1.2.2，表示安装1.2.x的最新版本（不低于1.2.2），但是不安装1.3.x，也就是说安装时不改变大版本号和次要版本号。
插入号（caret ^）+指定版本：比如ˆ1.2.2，表示安装1.x.x的最新版本（不低于1.2.2），但是不安装2.x.x，也就是说安装时不改变大版本号。需要注意的是，如果大版本号为0，则插入号的行为与波浪号相同，这是因为此时处于开发阶段，即使是次要版本号变动，也可能带来程序的不兼容。
latest：安装最新版本。
Patch releases: 1.0 or 1.0.x or ~1.0.4
Minor releases: 1 or 1.x or ^1.0.4
Major releases: * or x
以上的表示在pakage.json中都是合法的描述。除此之外，npm官方还提供了一个好用的工具，来告诉我们某个"表达式"会覆盖到哪些版本：https://semver.npmjs.com/
改动了依赖里的代码怎么办
这是上面说的那个祖传node_modules的真正原因了，由于当时mpvue一个包实现的问题，以及我们在原生语法写的项目中使用mpvue，我改动了包里的一行代码，这是我们的可以work，而到后端那里就会报错的根源所在。解决办法有这么几个：
1.提交给官方一个PR，等待merge
这个看官方的情况了，有可能很快merge，也可能快一年了还没个结果。可行性指数：
2. 将自己修改过的发一个包
这种方法需要有npm账户，然后熟悉publish package的流程。可行性指数：
3.fork一份到自己的github下，修改之后，直接让npm从github安装这个包
此时package.json中的对应的字段应该是这样：
"xxx": "git+https://github.com/xxx/koatest.git"
可行性指数：
在操作的时候注意一点，修改过的代码merge到master分支上，不然装完了还不能work（完）。