手记

通俗的告诉你,为什么是 devDependencies

纠结,dependenciesdevDependencies 有什么区别?我使用的包应该放到什么地方?上网找资料,大神群咨询。得到的答案是:

  • 生产环境用到的放在 dependencies中;
  • 开发环境用到的放在 devDependencies中;
  • 这是规范,遵守就能一起玩,不遵守就自己玩;

Emmm…大神就是喜欢说一些菜逼听不懂的话。但我就是想知道:如果我不遵守,会怎么样?

提出这个问题的朋友应该都发现:无论放到dependencies中,还是devDependencies,运行 npm install 时都会安装,没有差别,团队合作也OK,照玩不误啊。什么叫只能自己玩?把koa放到devDependencies中有没有问题?把webpack放到dependencies又会怎么样?

直到我要把自己的开源项目发布到 npm 时,才明白了大神的意思。

生产环境 or 开发环境?

先来看个问题:小明使用 webpack 开发 web项目 的环境,是什么环境?

答案是开发环境,但同时也是生产环境。

相对于 小明的项目开发环境,但相对 webpack,就是生产环境

从实践中理解两者的区别

用开源项目 debug 项目举例。它的 package.json 相关内容如下:

{
  "dependencies": {
    "ms": "^2.1.1"
  },
  "devDependencies": {
    "brfs": "^2.0.1",
    "browserify": "^16.2.3",
    "coveralls": "^3.0.2",
    "istanbul": "^0.4.5",
    "karma": "^3.1.4",
    "karma-browserify": "^6.0.0",
    "karma-chrome-launcher": "^2.2.0",
    "karma-mocha": "^1.3.0",
    "mocha": "^5.2.0",
    "mocha-lcov-reporter": "^1.2.0",
    "xo": "^0.23.0"
  }
}

使用debug (npm install debug)

我们在使用debug时,需要这样用(大部分用户的使用方式)

手动创建一个项目

npm init
npm install debug --save

查看 node_modules 目录中的内容

-- node_modules
  -- debug
  -- ms

可以看出, npm 只安装了 debugms(debug的dependencies包含的package)
因为现在的环境相对于 debug 来说,是生产环境,所以 npm 只安装了 debug 的生产依赖。

开发debug (git clone debug)

作为 debug 项目的 开发者二次开发者 ,才会这样用。

git clone https://github.com/visionmedia/debug.git
cd debug
npm install

查看node_modules

-- node_modules
  -- debug
  -- ms
  -- brfs
  -- xo
  -- connect
  -- date-format
  -- ...... 共653个package

可以看出, npm 安装了 dependenciesdevDependencies 以及 它们的dependencies
因为现在的环境相对于debug来说,是开发环境,所以npm安装了debug的所有依赖,以及它们的生产依赖。

对比以上结果,可以看出,一般情况下开发环境所需要安装的依赖远多于生产环境。

非常规玩法(挑战规范,知其所以然)

根据以上的实践分析,总结出一些法:

  1. 如果所有依赖包都是开放环境要用到的包,并且不会发布到npm让别人使用(如webpack打包完成后发布dist的前端项目),因为生产环境不再需要依赖这些包(甚至都不需要nodejs),这时你把依赖放到哪里,完全随你开心。但为了避免有人说闲话,应该放到devDependencies中。

  2. 如果所有依赖包都是生产环境要用到的包,并且不会发布到npm让别人使用。如web项目常用的expresskoa,是生产环境运行必须的包,你也可以随便放 (惊不惊喜意不意外),在生产环境中,部署生产环境时使用npm install,一样会把所有包安装下来,不影响生产环境的运行。为了避免有人说闲话,还是要放到dependencies中。

  3. 如果既有开发依赖又有生产依赖,并且不会发布到npm让别人使用。你还是可以随便放。npm install 会安装所有包。但就会产生问题,生产环境安装了开发环境的包,这个问题会死人吗?不太清楚,但项目是可以运行的。要避免这些额外的消耗,就要区分两种包的位置。在生产环境中使用npm install --production,则只会安装dependencies中的依赖。外翻篇:如果你开心,也可以把开发依赖包放到devDependencies生产依赖包放到dependencies,生产环境就用npm install --only=dev,这样只会安装devDependencies中的生产依赖。

  4. 如果是一个要发布到npm的项目,生产依赖就一定要放在dependencies中(缺失会导致运行出错);开发依赖应该放在devDependencies中,这样可以不浪费用户资源,如果放到dependencies中,用户端就会安装很多多余的依赖,浪费大量资源,增加版本冲突概率。

总结

简单总结,当生产依赖开发依赖分别放到不同位置时,会导致的问题:

玩法 dependencies devDependencies 内部项目 作为npm包发布
规范 生产依赖 开发依赖 - -
开发依赖放在dependencies中 生产依赖、开发依赖 - 浪费生产环境资源 浪费大量用户资源
生产依赖放在devDependencies中 - 生产依赖、开发依赖 浪费生产环境资源、部署方式怪异 用户无法正常运行
反着放 开发依赖 生产依赖 部署方式怪异 浪费大量用户资源、用户无法正常运行

可以看出,在内部项目中,只要团队能玩得转(也不关心生产环境的资源浪费),可以不用太在意规范。但如果是要发布到npm的项目,甚至是开源项目,就要特别注意。自己可以乱来,但给用户的,应该是最好的

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

热门评论

其实我感觉对于我们平时开发业务代码而言,其实都应该统统放到dev里。只有你这个项目是给别人用的,可能发布到npm上,是个工具类的项目,这个时候才应该区分出来

讲的非常好?,通俗易懂。比起其他人解释的只是翻译。 你讲出了 根本,为什么不可以,做了会怎么样。

查看全部评论