5-依赖预构建简介原创

Weight给我们提供了强大的功能，对于非常基础的使用者来说，使用weight开发和使用一个静态文件服务器没有太大的区别。然而V还通过原生的ESM导入，提供了许多主要用于打包场景的增强功能。我们先来介绍第一个功能NPM依赖解析和预构建。我们先来看看这句话，Import create view from view，这在我们开发view项目过程中是经常使用的一个导入view的语句，这句话呢，如果在浏览器上直接的进行呃解析的话，会报这样的一个错误，说他失败的解析了我们view的这个模块，让我们试图去看一看是不是路径有问题。其实事实上呢，这个导入是要导入我们do models这个文件夹下面的这个模块的，它并没有错误。那我们来演示一下，进入到我们上一小节创建的这个项目，在index atml里边通过右键open with life server来打开一个页面，我们点击右键检查一下控制台，我们看到404的错误，我们打开indextml，我们先把路径给修改一下，那么S2CJS里边我们看会通过import create view来载入view，这句话呢就已经报错了，这个错误信息刚才我们已经看了，那这个问题该怎么解决呢？

我们就通过来帮忙。那wait将会检测所有被加载的源文件中此类录模块的导入，并执行以下两个操作。第一个操作叫预构建，预构建呢可以提高页面的加载速度，并且将common JS umd转化为ESM格式预构件这一步是由ES build来执行的，这就使得wait的冷启动时间比任何基于javascript的打包器都要快得多。

那ES6的是什么呢？我们在后续章节里面会介绍，第二个呢，会重写导入为合法的URL。比如它可以把import create view from view这句话的路径改写为not modus.v view.js这样的一个URL，以便呢我们浏览器能够正确的导入他们。那预构件是如何工作的呢？我们接下来继续介绍。返回项目，我们执行一下PM PM run d，这样我们就可以重新的启动一下我们的项目了，可以通过local host3000来访问。我们按住键盘的command加鼠标单击，这样我们就可以在浏览器上面打开我们这个项目的还原页面。这些我们在前面已经了解了，下面呢，我们来看一个提示，当我们首次启动weight的时候，我们可以在控制台上面看到这样的一个提示，叫做prebounding depends说这里有些依赖的一个预构建，这里预构建的叫做view这个依赖。那我们来看一下man JS，这里面有一句叫做import create APP from view，那这句话呢，其实上如果在浏览器上面直接运行会有问题的，那我们得需要将这个所谓的叫common JS等等这样的一些模块载入的方法转化为ESM的方式，那wait会将这句话转化成浏览器能够识别的一个模块的载入方法，那它得需要一个所谓的叫做预构建的过程，那这个过程呢，仅仅发生在什么时候，当我们的依赖或者是配置文件发生变化的时候，它就会执行预构建。

那这个依赖于构建的过程，其实实现的是两个目的，第一个呢，就是完成common JS和umd的兼容。

我们知道，在开发阶段中，V的开发服务器会将所有的代码视为原生的ES模块。那么V必须先将作为这个common JS以及umb发布的依赖项转换为ESM。当转换common JS依赖的时候，V会执行智能的导入分析，这样即使导出的是动态分配的，比方说像view。那按名字进行导入也能够达到预期的效果，比如这句话就能够完成任务。那第二个呢，就是性能方面，Wait会将许多内部的模块的ESM依赖关系转化为单个的模块，以提高我们后续页面加载的性能。一些包将他们的ES模块的构建作为许多单独文件相互的导入。比如ES这里头我们有一个load带，那load带SHES我们再去导入的时候呢，其实事实上有超过600个内置的模块需要一起导入。

我们在浏览器上面看一下，这里我们打开叫做UN package这样的一个网站，在这里边我们找到load ES的4.17的版本，我们看到这里的提示就大概达到了600多个文件。那如果是我们执行了这句话，那浏览器呢，会同时发出600多个HTTP请求，尽管我们服务器端在处理这些请求的时候呢是没有问题的，但是大量的请求会在浏览器端造成网络用色，导致页面的加载速度相当的慢，那通过预构件我们捞带是ES的话，把它变为一个模块，我们只需要做一次HTTP请求就够了。另外呢，V可以实现自动的依赖搜索。默认情况下，在模块预构建完成以后，对构建好的模块会进行缓存。如果他没有找到相应的缓存，Wait会抓取我们的源码，并自动寻找引入依赖项。比如期望我们从node models来去解析，那它会从这些依赖项作为我们构建包的入口点。

那预构建是通过ES build来执行的，所以它非常的快。在服务器已经启动以后，如果遇到一个新的依赖关系需要导入，而这个依赖关系还没有在缓存中，那么V将重新运行依赖构建的进程，并重新加载页面。另外，VT默认的依赖发现为启发式的。这个可能并不总是我们想要的，我们想要显示的从列表中包含或者排除依赖项的这种情况，那我们可以使用optimize deps这个配置项。当我们遇到不能直接在源码中发现import的时候呢？这两个配置项就相当的典型。

这两个配置项，一个是叫做optimize de.exclude以及optimize.de。那我们举个例子，比如我们import可能是插件转化的结果，这就意味着wait无法在初始扫描的时候发现import，它只能在浏览器请求文件的时候转化以后才能发现，这样呢会导致服务器在启动以后立即重新打包。那么我们使用include和X就可以解决这样的问题了。这两个配置项我们使用哪一个呢？要看具体情况。如果我们的依赖项很大，包含很多的内置模块或者是common GS，那么我们应该使用include。如果依赖项很小，并且已经是有效的ESM了，那我们可以排除它使用exclude，让浏览器直接加载它。我们回到代码来真实的感受一下，这里呢，我们需要在v conflict JS的def DeFine conflictig里面去pay op my steps这里有个对象，我们可以通过include来去，呃，导入一个ESM de这样的包，这个包呢是虚构的，将来我们可以写入我们真实的一些需要我们包含的一些包，这里定义的是个数组，我们就可以包含很多的这样的一些去编译的一些包，我们可以把它保存一下，然后在控制台上面呢，我们重新的去启动一下我们这个服务。

你会发现这里呢，他说强制的去导入我们一个包ESM dip会发生的问题，原因是因为我们这个ESM dip是虚构的，将来它如果是一个真实的包的话呢，它就会把我们这个包导入到我们这个项目里来了。好，这就是本节我们来介绍的关于所谓的叫做模块预构件的一些细节。