浅谈一个webpack构建速度优化误区

关于Webpack构建速度优化误区的——以长沙网络推广为例

近日，长沙网络推广分享了一个关于Webpack构建速度优化的案例，引发了广泛关注与讨论。今天，让我们一起来深入这个问题，看看在项目中遇到的一些构建问题究竟应该如何解决。

让我们来了解一下问题的描述。在一个项目中，团队使用了npm包a，之前一直运行得很好。在某次拉取其他分支的代码后，项目突然出现了Bug。尽管检查了项目的package.json和package-lock.json文件，确认模块和依赖信息并未改变，但问题仍然存在。

我们需要深入了解node_modules的目录结构。从目录结构中可以看到，模块a的目录下还有一个node_modules目录，里面存放的是模块a的依赖。令人困惑的是，项目本身的node_modules目录和模块a的node_modules目录中都有安装了模块c。为什么会这样呢？

这其实是npm的模块安装机制导致的。假设项目依赖了模块a和模块b，而模块a依赖模块c的1.0.0版本，模块b依赖模块c的2.0.0版本。在npm2时代，模块c会被分别安装到a和b模块的node_modules目录中，导致node_modules目录结构冗余复杂。而在npm3时代，npm对模块的安装方式进行了优化，尽量将模块安装到最外层的node_modules目录中，以实现模块的复用。在某些情况下，如模块版本不兼容时，还是会将模块安装在父模块的node_modules目录中。

回到我们遇到的问题，虽然项目没有直接引用模块c，但是因为模块a和模块b对模块c的不同版本产生了依赖冲突，导致了项目中存在两个版本的模块c。这时候，问题出现了。当我们尝试在node_modules/a/node_modules/c/index.js中添加日志时，居然没有执行！通过检查webpack的resolve.mainFields属性以及模块c的package.json文件信息后，我们发现原来在引用模块时，webpack的查找方式和Node.js并不完全一样。在向上查找的过程中，它首先会在当前目录下的node_modules目录中查找，如果没有找到，再向上级目录查找。在这个案例中，我们发现项目实际上引用的是最外层node_modules中的模块c。

这个案例让我们明白了一个重要的道理：在进行Webpack构建速度优化时，我们需要深入了解npm的模块安装机制和webpack的引用规则。只有这样，才能避免陷入误区，更好地优化项目构建速度。长沙网络推广也给我们提供了一个很好的参考案例，让我们在面临类似问题时有了更多的思考方向。希望这篇文章能给大家带来启示和帮助。Webpack配置中的模块检索问题

Webpack作为一种模块打包工具，其配置对于项目的构建至关重要。近期，我们遇到了一些关于模块检索的问题，经过深入研究和排查，我们发现这些问题可能与Webpack的某些配置有关。

在我们的项目中，我们使用了如下的基本webpack配置：

```javascript

const path = require('path');

module.exports = {

entry: './src/index.js',

output: {

filename: 'main.js',

path: path.resolve(__dirname, './dist/js')

},

};

```

在问题的过程中，我们开始关注与模块检索相关的webpack配置，特别是resolve属性。我们的项目中的resolve配置如下：

```javascript

const config = {

resolve: {

modules: [

path.resolve(projectDir, 'src'),

path.resolve(projectDir, 'node_modules'), // 这里使用了绝对路径

path.resolve(imtPath, 'node_modules'), // 以及这里也是绝对路径的node_modules目录配置。尝试优化模块检索速度，却导致了Bug。

],

mainFields: ['jsnext:main', 'browser', 'main'], // 用于模块的字段顺序。这是ES tree-shaking的一个重要特性。无需多言，默认的字段顺序可以帮助我们在打包过程中更有效地利用ES的特性来减少最终生成的代码体积。但在这个问题中并未涉及该字段的具体问题。

alias: {}, // 用于定义模块的别名，方便我们引用模块时避免复杂的路径问题。但在本次问题排查中并未发现此处的配置问题。

extensions: ['.jsx', '.js'], // 定义webpack模块时的文件扩展名列表。在这个问题中并未涉及此字段的具体问题。

}

}

```

在对照webpack官方文档进行排查时，我们找到了问题的关键所在：使用绝对路径配置resolve.modules导致的Bug。在webpack文档中，关于resolve.modules的描述是这样的：告诉webpack在模块时应该搜索的目录。绝对路径和相对路径都可以使用，但它们的行为有所不同。相对路径（如"./node_modules"）会根据当前目录和祖先目录（如../node_modules）进行查找，类似于Node查找'node_modules'的方式。而使用绝对路径时，webpack只会在给定的目录中搜索。这就意味着，如果我们在resolve.modules中使用项目的node_modules目录的绝对路径，webpack会在查找模块时忽略更深层次的同名模块，可能会导致使用错误的npm包。这个问题与npm的包安装策略有关，npm会优先将包安装在node_modules目录的最外层，除非有冲突才会安装到父模块下的node_modules中。为了避免这个问题，我们应该将resolve.modules中的绝对路径改为相对路径或默认的node_modules目录。这样修改后，webpack就能正确地查找并使用npm安装的包了。这就是我们遇到的问题和解决方案。希望这篇文章能对你有所帮助，也希望大家多多支持我们的博客——狼蚁SEO。