Webpack vs Vite vs Rollup：配置工程师的噩梦

现代前端构建工具层出不穷，Webpack、Vite、Rollup 各有拥趸，但配置复杂度让开发者头疼。从零开始搭建项目时，面对配置文件里密密麻麻的选项，工程师们常常陷入"选择困难症"。

Webpack：配置界的瑞士军刀

Webpack 的配置文件堪称前端工程的"教科书级案例"。一个基础的生产环境配置至少需要处理以下问题：

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'bundle.[contenthash].js',
    path: path.resolve(__dirname, 'dist')
  },
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env']
          }
        }
      },
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader', 'postcss-loader']
      }
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({ template: './public/index.html' }),
    new MiniCssExtractPlugin()
  ]
}

典型痛点包括：

• 处理不同资源需要不同 loader（图片、字体、CSS 预处理器等）
• 开发/生产环境需要不同配置（sourceMap、代码压缩等）
• 代码分割策略需要手动优化
• 热更新配置可能与其他工具冲突

Vite：闪电速度背后的配置陷阱

Vite 虽然号称"开箱即用"，但实际项目中的配置复杂度可能超乎想象：

// vite.config.js
export default defineConfig({
  plugins: [
    react(),
    legacy({
      targets: ['defaults', 'not IE 11']
    })
  ],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src')
    }
  },
  build: {
    rollupOptions: {
      output: {
        manualChunks: (id) => {
          if (id.includes('node_modules')) {
            return 'vendor'
          }
        }
      }
    }
  }
})

常见配置难题：

• 传统浏览器兼容需要额外 polyfill 配置
• SSR 模式下的特殊处理
• 与后端 API 代理的路径匹配规则
• 自定义 Rollup 配置时的类型提示丢失

Rollup：库开发的精密手术刀

Rollup 的配置看似简洁，但细节把控令人抓狂：

// rollup.config.js
import { terser } from 'rollup-plugin-terser'

export default {
  input: 'src/index.js',
  output: [
    {
      file: 'dist/bundle.esm.js',
      format: 'esm'
    },
    {
      file: 'dist/bundle.cjs.js',
      format: 'cjs'
    }
  ],
  plugins: [
    resolve(),
    commonjs(),
    json(),
    terser({
      compress: {
        drop_console: true
      }
    })
  ],
  external: ['react', 'react-dom']
}

典型问题场景：

• 多输出格式时插件重复处理问题
• CommonJS 与 ESM 混用时的诡异报错
• 外部依赖排除策略的精确控制
• Tree-shaking 失效时的调试困难

配置地狱的生存指南

面对这些工具，可以尝试以下实践：

1. 配置分层：将基础配置、环境配置、插件配置分离

// webpack-common.js
module.exports = {
  // 公共配置
}

// webpack-dev.js
const common = require('./webpack-common')
module.exports = merge(common, {
  // 开发配置
})

2. 类型安全：使用 JSDoc 或 TypeScript 增强配置提示

import { Configuration } from 'webpack'

const config: Configuration = {
  // 获得完整类型提示
}

3. 配置验证：使用 schema-utils 校验配置

import { validate } from 'schema-utils'
import schema from 'webpack/schemas/WebpackOptions.json'

validate(schema, config)

4. 可视化工具：利用 Webpack Dashboard 或 Vite 插件分析配置

工具链的版本矩阵

不同工具版本的配置差异可能造成严重问题：

性能调优的黑暗艺术

构建性能优化往往需要非常规配置：

Webpack 的持久缓存配置：

module.exports = {
  cache: {
    type: 'filesystem',
    buildDependencies: {
      config: [__filename]
    }
  }
}

Vite 的预构建优化：

optimizeDeps: {
  include: ['lodash-es'],
  exclude: ['vue-demi']
}

Rollup 的并行处理：

import { rollup } from 'rollup'

const builds = await Promise.all([
  rollup(inputOptions1),
  rollup(inputOptions2)
])

生态系统的兼容拼图

混合使用不同工具时的配置冲突：

1. Storybook + Vite：需要维护两套插件配置
2. Jest + Webpack：需要模拟 webpack 的 resolve 逻辑
3. ESLint + Rollup：需要同步 import 解析规则

// 解决 Vite 与 Jest 的别名冲突
module.exports = {
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1'
  }
}