使用CopyWebpackPlugin复制node_modules中Font Awesome字体至build/public目录时出现‘Plugin name should be specified’报错的问题求助

咱们先拆解下你遇到的核心问题：尝试用CopyWebpackPlugin批量复制@fortawesome/fontawesome-free/webfonts整个目录时，触发了ERROR in Plugin name should be specified的报错，但单独复制单个文件、删除目录里的3个.svg文件后就能正常构建。这本质是CopyWebpackPlugin和file-loader的处理逻辑冲突导致的，尤其是.svg这类兼具字体和图片属性的文件，容易引发webpack内部的处理混乱。

问题根源分析 #

你的file-loader规则原本覆盖了.svg等字体文件，当CopyWebpackPlugin尝试批量复制整个webfonts目录时，会把这些.svg文件纳入复制范围，但file-loader同时也在处理同一批文件，两者的资源处理流程发生冲突，进而抛出了这个指向模糊的报错（并非真的是插件名称未指定）。

可行解决方案 #

这里提供两种针对性的解决思路，你可以根据自己的项目需求选择：

方案一：让CopyWebpackPlugin跳过已被file-loader处理的文件 #

修改CopyWebpackPlugin的配置，添加globOptions排除会被file-loader处理的字体文件类型，避免重复处理：

new CopyWebpackPlugin({
  patterns: [
    { from: Path.resolve(__dirname, '../public'), to: 'public' },
    {
      from: Path.resolve(__dirname, '../node_modules/@fortawesome/fontawesome-free/webfonts'),
      to: 'public/fonts',
      globOptions: {
        // 排除file-loader负责处理的字体文件
        ignore: ['**/*.svg', '**/*.eot', '**/*.ttf', '**/*.woff', '**/*.woff2']
      }
    }
  ]
}),

同时保留你修改后的file-loader字体规则，让file-loader自动将这些字体文件输出到fonts/目录，既利用loader的资源处理能力，又避免和CopyWebpackPlugin冲突。

方案二：用CopyWebpackPlugin全权处理Font Awesome字体，让file-loader排除该目录 #

如果你更倾向于用CopyWebpackPlugin完成批量复制，可修改file-loader规则，排除Font Awesome的webfonts目录：

{
  test: /\.(eot|otf|webp|svg|ttf|woff|woff2)(\?.*)?$/,
  exclude: [
    Path.resolve(__dirname, '../public/images'),
    // 让file-loader跳过Font Awesome的字体文件，交给CopyWebpackPlugin处理
    Path.resolve(__dirname, '../node_modules/@fortawesome/fontawesome-free/webfonts')
  ],
  use: {
    loader: 'file-loader',
    options: {
      name: '[name].[ext]',
      outputPath: 'fonts/'
    },
  },
},

之后保持你原本的CopyWebpackPlugin配置即可，file-loader不再干预Font Awesome的字体文件，插件就能顺利完成整个目录的复制。

验证测试 #

修改配置后，重新运行webpack构建命令，应该就能正常把webfonts目录下的所有文件（包括之前报错的.svg）复制到build/public/fonts目录中了。

内容的提问来源于stack exchange，提问作者Devart