#Babel

Add Babel only when you need transforms or plugins that SWC does not cover. Keep SWC as the default pipeline, then scope Babel to the files that need it.

#When Babel is a good fit

• You depend on Babel-only plugins or presets.
• You are migrating an existing Babel-heavy project incrementally.
• You want targeted transforms for specific file types (for example MDX).

#Babel capabilities

#Example setup

Install Babel dependencies:

npm install -D @babel/core @babel/preset-env babel-loader

yarn add -D @babel/core @babel/preset-env babel-loader

pnpm add -D @babel/core @babel/preset-env babel-loader

bun add -D @babel/core @babel/preset-env babel-loader

deno add -D npm:@babel/core npm:@babel/preset-env npm:babel-loader

Create babel.config.json:

{
  "presets": ["@babel/preset-env"]
}

Wire Babel into extension.config.js for MDX only:

export default {
  config: (config) => {
    config.module.rules.push({
      test: /\.mdx$/,
      use: ['babel-loader', '@mdx-js/loader']
    })
    return config
  }
}

#Replace SWC for JS/TS only if required

Use this pattern only when you need Babel to process JS/TS entry files directly:

export default {
  config: (config) => {
    config.module.rules = [
      {
        test: /\.[jt]sx?$/,
        exclude: /node_modules/,
        use: [{loader: 'babel-loader'}]
      },
      ...config.module.rules.filter(
        (rule) => !String(rule?.test || '').includes('[jt]sx')
      )
    ]
    return config
  }
}

#Best practices

• Prefer targeted Babel usage before replacing the default JS/TS pipeline.
• Keep Babel rules explicit so loader ordering stays predictable.
• Reuse Babel only where migration or plugin compatibility requires it.

#Next steps

• Learn how to customize Rspack configuration.
• Keep code quality high with ESLint.