webpack loader执行顺序 css-loader和style-loader的底层执行原理

我们在使用webpack对代码进行处理时，难免会用到loader对文件进行处理，多个loader对一个文件进行处理，难免会涉及到哪些loader先执行的问题，下面让我们来了解一下。

首先，我们所写的loader是从下到上执行的，如下图

假设存在这三个loader存在并对js文件进行处理，那么他们的执行顺序就是03>02>01，那么为什么如此奇怪呢，为什么要从下向上进行处理呢，因为每个loader还有一个属性pitch，是一个函数（loader本身也是一个函数） ，我们称这个属性未pitchloader，而我们的loader称为normalloader，runloader函数在遍历执行loader时（源码中的函数，想要了解webpack源码，可以看我的另一篇文章webpack源码解析），它首先遍历pitchloader，并将index++，在遍历normalloader，并将index--，这样便形成了先正着调用pitchloader，在反向调用normalloader，具体流程如下

 其中pitchloader并不接受源文件，但偶尔需要它处理源文件，我们下文中会讲到

而normalloader就是主要的处理源文件的函数了，他们在处理完源文件后会交给下一个loader再次处理，我们现在就是要发现，他们的先后执行顺序。

上文说了，执行顺序是正序执行pitchloader，逆序执行normal，那么有什么方法可以配置他们的顺序吗？当然有

 如图所示，当我们给每个loader分别配置enforce属性，顺序就被打乱了，首先pre会最先执行，不配置的默认未normal，配置post的最后执行，与之相反的是pitchloader，他与normalloader执行顺序相反。

除了上面三种loader，还有一种inlineloader，他的执行顺序是在post之前，为什么要单独拿出来说呢，因为它有一些不一样。

如上图，图中路径的意思是，后面是要解析的文件，解析文件前面是一个感叹号，这个感叹号的作用是阻隔loader的路径和被解析文件的，再向前有两个感叹号，还可以设置成！以及-！，具体含义如下

!表示所有的normal loader全部不执行（执行pre,post和inline loader）

-！表示所有的normal loader和pre loader都不执行（执行post和inline loader）

!! 表示所有的normal pre 和 post loader全部不执行（只执行inline loader）

其中，我们写在require中的loader（这个loader4是不再rule中的）便被成为inlineloader

这段代码通常在pitchloader中调用，在执行这段代码之后，执行完这次的全部loader（如果在pitch loader中调用，那么本次loader将不会全部执行，因为pitchloader具有熔断效果，下面我就会将），还会出现第二论loader调用，针对这个路径下的文件，并且根据！决定调用那些loader，并且按照上文中说的顺序来执行。

loader的执行顺序，还与pitchloader有关，不仅仅是他的优先执行，还有它具有的熔断效果。

什么是熔断效果，让我们看下面这个图

一旦pitch返回了不为undifend的值，loader就不会继续执行，而是会跳到上一个loader的normalloader中执行代码，如果此次为第一个pitchloader的话，那么本次loader的处理直接结束，不过通常在pitch有返回值时，pitchloader都是会调用inlineloader的，所跳出第一轮loader是为了执行某些功能，并不是不使用loader解析代码了，后文我会给出例子。

pitchloader不同于normal接收文件，处理文件，它具有三个参数，分别为

remainingRequest：在本次loader之后的loader（不包括本次，并且为路径）

previousRequest：在本次loader之前的loader（不包括本次，并且为路径）

data：数据，pitchloader中定义，可以在对应的normalloader中获取

那么pitchloader到底有什么作用呢，其实我也不太清楚，但我给大家讲一个大家熟知的例子，大家自己理解吧，那就是cssloder和styleloader

这个两个loader大家都很熟悉，我们经常使用，并且我们要把styleloader写在上面，cssloader写在下面，这样让cssloder先解析，将路径内文件进行解析，在由styleloader将解析结果插入打包结果中，完成对css的打包。

这些是大家都熟知的，那么我来说一些大家可能不知道的，那就是styleloader的功能其实是在pitchloader中实现的，经过上面的学习，我们大家知道了，pitchloader是要比normalloader先执行的，那styleloader不就比cssloder先执行了吗？没错，styleloader确实是最先发挥作用的，但是它仍然需要cssloader先进行解析，得到他的结果，那他是怎么做到的呢？

这是styleloader的pitch中的代码，styleloader的pitch通过inlineloader的方式调用cssloder处理css文件，并且拿到最终返回值在进行处理，最终返回返回值，终止loader的继续解析，这样即使styleloader的pitch在cssloader的normal前执行，也能拿到cssloader处理代码的返回值，但为什么要这么做呢？这不是多次依据吗？

问题就出在cssloader处理完代码，返回给下个loader函数的参数是一个模块，函数接收模块为参数，闻所未闻，根本不知道怎么拿到里面的导出值，所以styleloader不得已在pitch中通过上图方法来调用cssloader来处理代码，这样styleloader可以通过import再将cssloader返回的模块内部的导出值引入。

讲完这个例子，大家就可以自行理解pitchloader的作用了