手记

没搞懂的package.json

事情是这样的,今天上午,后端同学 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(完)。

参考资料

作者:nobody-junior

原文出处:https://www.cnblogs.com/imgss/p/package-json.html  

0人推荐
随时随地看视频
慕课网APP