本文主要是介绍vite是如何实现依赖预构建的，浏览器为什么没有实现从node_modules查找依赖，vite开发环境解决了什么问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
浏览器的esmodule 为什么没有做从node_modules查找依赖项
浏览器是基于http请求的，node_modules中依赖项不可控，可能又会依赖很多的包，整个依赖图都需要加载的话很耗性能。 commonjs是运行在服务端的，以file形式读取文件，内部有规避机制。
依赖预构建
首先vite会找到对应的依赖，然后调用esbuild(对js语法进行处理的一个库)，将其他规范的代码转换成esmodule规范，然后放到当前目录下的node_modules/.vite/deps【注: 缓存目录】，同时对esmodule规范的各个模块进行统一集成
node_modules三方包依赖图问题，将有依赖的包汇总导出到一个文件中。
解决了三个问题
- 不同的第三方包会有不同的导出格式(这个是vite没法约束人家的事情)
- 对路径的处理上可以直接使用.vite/deps，方便路径重写
- 网络多包传输的性能问题(也是原生esmodule规范不敢支持node_modules的原因之一)
有了依赖预构建以后无论他有多少的额外export 和import； vite都会尽可能的将他们进行集成最后只生成一个或者几个模块
思考题：webpack 能不能做vite这种冷启动优化?
个人觉得不太会做，一旦要改，那么将会动到大动脉。webpack支持多种模块化，commonJs， esmodule等
webpack的编译原理，AST抽象语法分析工具，分析出你写的js文件有哪些导入和导出操作，构建工具会监测你的代码文件，及时输出结果。冷启动时基于esmodule实现的。
因为webpack支持多种模块化，他一开始必须要统一模块化代码，所以意味着他需要将所有的依赖全部读一遍，
webpack更多关注兼容性，多端（可能是node）， vite更多关注浏览器开发体验。
这篇关于vite是如何实现依赖预构建的，浏览器为什么没有实现从node_modules查找依赖，vite开发环境解决了什么问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
