近期有了时间做一些自己的东西,中间发现一个有趣的问题,纠正了我一直以来的错误思维,所以发一篇博客记录一下
答案
先抛结论,如果是做普通前端项目的话,其实package.json里面的依赖包作为开发依赖和生产依赖基本没啥区别,就算把项目的package.json中的dependencies包全部挪到devDependencies也没问题。如果项目是做npm包或者node服务的,会有些许差别
背景
我们都知道package.json的dependencies对应生产环境依赖,devDependencies是开发环境依赖。用npm install
的时候加上–save是添加到dependencies,–save-dev把模块添加到devDependencies部分。
在研究gatsby.js的时候,我发现官方推荐把typescript安装在dependencies里面…
我就很好奇,因为在我印象里,ts只是静态类型检查约束的,真正生产上线的都是js,为什么要把它放在dependencies里面?上线的时候会不会把它也打进最终的产品中去?
于是我google了typescript应该放在哪里,结果发现很多这样的issue,一个是在create-react-app里面默认就把typescript加入到了dependencies,也引起了别人的疑问,见下图
问答
丹(react开发者)说:”无所谓,你想放哪就放哪😜”…
接下来,他跟了一段话,简单解释了下:
dependencies和devDependencies的区别对于Node应用服务是有意义的,因为它们实际上是作为运行时(runtime)部署的。因此,您可能不想部署devDependencies。
对于create-react-app这样的脚手架,最终结果是生产出静态的bundle。因此,从某种意义上说,所有依赖包都应该是“dependencies”,甚至是您使用的React或库。因为它们仅在构建时使用。
将所有依赖包放入devDependencies可能会破坏某些在服务器上进行初始build的部署脚本。因此,将所有依赖包放到dependencies中会更容易些。
提到的issue地址👇
还有一个相似的问题 github.com/facebook/cr…
原理
dependencies和devDependencies是package.json
里面的配置,而package.json
和node_modules
这套依赖包加载机制是node设计出来的。
我们如果开发一个node应用,这个后端服务需要部署上线,确实要尽量严格区分dependencies和devDependencies,因为项目本身就是运行态,如果部署上线我们不会希望把开发态的一些工具,例如测试框架等,带到线上。
如果开发npm包也是有区别的,假设我们开发npm包A,并把它发布,在某个项目中引入了依赖包A,A下载的话也有自身的node_modules
,如果A的依赖里有B,B在dependencies的话就会一起被下载到A的node_modules
,如果是开发的话,就不会下载,这样我们写npm包A的时候,要把webpack或者gulp或者jest等开发依赖放到devDependencies,来减少别人使用A时下载的包大小。
如果是普通的SPA前端项目,那确实没啥区别,因为我们实际上是用的项目生产出来的静态页面文件,部署的时候部署的页面也只是webpack打包生产出来的产品,所以依赖包放在dependencies和devDependencies没啥区别。
但是多说一嘴:有些自动构建工程build脚本会加上–production的参数,这个时候不会拉devDependencies的包,导致build流程异常,所以丹建议我们尽量都放到dependencies里面!
拓展
有兴趣的还可以了解一下 peerDependencies、bundledDependencies、optionalDependencies这些是什么依赖,不过注意要慎用!
今天的文章开发依赖和生产依赖到底有何区别分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/15235.html