Question

更新＆安培;回答：

我的误解是：

所有导入/需要的文件都将由loader进行转换。

但是，某些导入/必需的文件无需转换。例如，＆＃34; node_module＆＃34;中的js文件已经处理完毕。因此，Babel装载机无需再次进行转换。这基本上就是我们需要＆＃34;排除：/ node_modules /＆＃34;在装载机中。

同样，如果你知道加载器要转换的文件，你可以使用＆＃34; include＆＃34;。

简单地说，entry.js将包含所有导入/必需的文件。但在这些文件中，只有少数文件需要转换。这就是为什么＆＃34; loader＆＃34;介绍＆＃34;包括＆＃34;和＆＃34;排除＆＃34;。

我仍然不太清楚我们需要使用的原因＆＃34; include＆＃34;或＆＃34;排除＆＃34;在webpack的加载程序中。

因为条目js文件总是需要递归地包含其导入/必需的js文件。所有导入/必需的文件都将由loader转换。如果是这种情况，为什么我们需要＆＃34;包括＆＃34;或＆＃34;排除＆＃34;在装载机？

一个常见的情况是＆＃34;排除：/ node_modules /＆＃34;。令我困惑的是，如果条目js文件需要来自node_modules的一些文件，那么我们将排除node_modules。然后最终的bundle文件将不包含node_modules中的requied文件。在这种情况下，最终的bundle.js将无法正常工作。我在这里错过了什么吗？

module.exports = {
  entry: [
    './index.js'
  ],
  output: {
    path: path.join(__dirname,"public"),
    filename: 'bundle.js'
  },
  module: {
    loaders: [{
      test: /\.js$/,
      loader: 'babel',
      exclude: /node_modules/,
      query: {
          presets: ['es2015']
        }
    }]
  }
};

由于

德里克

Answer 1

问题在于，如果没有exclude（或include），当您在代码中指向它们并处理它们时，webpack将遍历依赖项。即使这样可行，也会带来严重的性能损失。

我更喜欢自己设置include（黑名单上的白名单），这样可以让我更好地控制行为。我include我的应用程序目录，然后根据需要向include添加更多项目。这使我可以轻松地设置异常，并在绝对需要的情况下处理来自node_modules的位。

Answer 2

到目前为止，答案还没有真正回答你的核心问题。您想知道捆绑的应用程序如何仍然能够正常运行，即使其依赖项已被“排除”。

实际上，那些“包含”和“排除”属性告诉 加载者 是否要包含/排除所描述的文件（例如{{1}的内容}）， 不是webpack本身 。

因此，您从node_modules 导入的“已排除”模块将被捆绑 - 但 将不会被转换 来自巴贝尔。这通常是理想的行为：大多数库已经被编译到ES 5.1（甚至是ES 3），因此浪费CPU周期用babel（例如）解析它们充其量是没有意义的。在最坏的情况下，就像像jQuery这样的大型单文件库，它会抛出错误并使你的构建停止崩溃。因此，我们排除node_modules。

如何＆＃34;包括＆＃34;和＆＃34;排除＆＃34;适用于webpack loader

更新＆安培;回答：

2 个答案: