我们都知道dependencies 和devDependencies 的是我们记录当前项目所使用依赖的地方，执行npm install之后就会以这两个对象为依据去下载我们当前项目所需要的依赖包。那他们俩到底有什么区别呢？

首先从字面上来理解，devDependencies 指的就是开发环境所需要的依赖，而dependencies则是生产环境所需要的依赖了。当然大部分文章也是这么描述的。说一些生产环境不需要用到的依赖放在devDependencies，生产环境需要的依赖放在dependencies。

但如果你真的是这样认为的那就大错特错了。事实并非如此，我们都知道工程化的构建工具是通过分析依赖的引入来打包整个项目所需要用到的文件的。再加上不断的优化，three shaking的出现，使得一些没有被用到的包根本不会被打进最终产物。所以即使我们在dependencies中写了开发环境所需的包，但只要我们的代码中没有引入他，他都是不会被打包进最终产物的。

换句话说，这两个东西对于一个业务项目来说，依赖写在哪儿都无所谓。都不会影响最终结果。但是规范的去归类也是没有任何问题的。

那么问题来了，既然依赖写在哪儿都无所谓的话，为啥还要区分出这两个属性出来呢，干脆放在同一个属性里不就好了。

仔细回想一下，上文说了，如果是对于一个业务项目来说，他没有什么区别。那么对于其他项目是不是就会起到不一样的作用了？

在去探秘之前，让我们先回顾一下依赖安装相关的知识。

当我们下载一个外部依赖库的时候，这个库可能也依赖了别的库，那么在下载的时候，当然是需要把这个库所依赖的库也一起下载进来。那么npm怎么知道这个库依赖了哪些库呢。答案当然就是根据库的package.json 文件中的dependencies来决定了。所以这个时候如果那个库的dependencies没有写他所依赖的库的话，是不是就会导致这个库没办法正常运行了。

讲到这里是不是开始有点能理解这俩兄弟的作用了。当我们在开发一个外部资源库的时候，我们就需要严格的去区分dependencies 和devDependencies。严格的按照运行时所依赖的库和生产环境所以来的库做区分，这样才不会导致我们开发的库被用户使用时造成意想不到的错误。npm在下载依赖库的依赖的时候只会下载dependencies中的东西，不会去下载devDependencies的东西。如果我们将开发环境用到的库写到了dependencies中，那就会无故占用用户的资源空间。因为这些东西用户在使用的时候根本用不着。

当然如果你的资源库是一个已经构建过得包那就不会出现这样的问题了，因为你的包在构建的过程中就已经将所需的库一起打包进去了。当然这样的话你就需要配置你的暴露项为编译后的产物，让用户直接引入编译之后的代码。