全新的项目构建方案——vite

目录

为什么快？

这种机制会存在问题吗？

官方如何解决的这种问题？        

为什么选择了vite？

---

为什么快？

        welbpack 在开发时构建时，默认会去 抓取并构建你的整个应用，然后才能提供服务，这就导致你的项目中，存在的任何一个错误（哪怕这个错误是在用户从来都没有进入过的页面中出现的），它依然会能响到你的整个项目构建。

        vite不会在一开始就构建你的整个项目，而是会将应用中的模块区分为 依赖 和 源码（项目代码）两部分，对于 源码 部分，它会根据 路由来拆分 代码模块，只会去构建一开始就必须要构建的内容。

        同时 vite 以 原生 ESM 的方式为浏览器提供源码，让浏览器接管了 打包 的部分工作。

        因为这样的一个机制，无论你的项目有多大，它只会构建一开始必须要构建的内容，这就让 vite在构建时的速度大大提升了。

        这也是 vite 为什么会快的一个核心原因。

这种机制会存在问题吗？

        如果大家对 ESM 的构建机制有了解的话，那么应该可以发现一个问题。

        那就是 vite 既然以 原生 ESM 的方式为浏览器提供源码，让浏览器接管了打包的部分工作，那么假如我们的项目中存在 commonJs 的内容怎么办？是不是就意味着无法解析呢？

        是的！

        在 vite 的早期版本中，确实存在这个问题，这个问题导致的最核心的麻烦就是很多的 依赖 无法使用。

        比如 axios 因为 axios 中使用了很多的 commonJS 规范，这就让 vite 无法解析对应的内容（对应的 issue），从而会拋出一个错误，关于这个问题曾经也在 vite 的 issues 中进行过激烈的讨论。

 尤大也对此进行了发言：

        Closing as wontfix since remote-redux-devtools seems to be a CommonS module that Rollup simply cannot handle

        Vite will not go out of its way to support arbitrary CommonS deps, and I think for a new tool like Vite, we should take the opportunity to push users to prefer ESM compatible libraries and move the ecosystem forward.

官方如何解决的这种问题？        

        因为这个问题非常的严重，所以针对于这个问题，vite 在后期提供了 依赖预构建(https://cn .vitejs.dev/guide/dep-pre-bundling.html)的功能，其中一个非常重要的目的就是为了解决 CommonJs 和 UMD 兼容性 问题。目前 vite 会先将 CommonJs 或 UMD 发布的依赖项 转换为 ESM 之后，再重新进行编译。这也可以理解为 速度对业务的一个妥协。

为什么选择了vite？

        目前最新的 vite 版本为 4.49 的版本，经过了三年多的更新的之后，现在的 vite 已经非常成熟，足以满足 企业级开发的需求，并且经过调研，越来越过得企业开始尝试使用 vite 作为项目的构建工具，根据npm 的周下载量可以看出，目前 vite 的周下载量 已经达到了 611万。