Skip to content
Back to skills

Babel Pro

ASecurity

Configure Babel: presets, plugins, env-specific builds, polyfills, and performance. Use when maintaining Babel-based toolchains or writing custom transforms.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 29, 2026
ai-agentsjavascripttypescriptgojavareactnodeapiperformance

Works with

  • api

Security analysis

A100/100

Scanned September 29, 2026

npx -y skills add aicodedecode/awesome-muse-skills --skill babel-pro --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Babel Pro?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Babel Pro
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/aicodedecode-babel-pro/badge)](https://www.skillsdirectory.com/skills/aicodedecode-babel-pro)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: babel-pro
description: Configure Babel: presets, plugins, env-specific builds, polyfills, and performance. Use when maintaining Babel-based toolchains or writing custom transforms.
category: development
---

# Babel Pro

A practical guide to Babel: presets and plugins, environment-specific configuration, polyfill strategy, and performance — for the many codebases where Babel is still the transform layer, and for anyone writing custom Babel plugins.

## Overview

Babel transforms JavaScript via a plugin pipeline: **parse → transform (plugins) → generate**. Presets are plugin bundles (`@babel/preset-env`, `@babel/preset-react`, `@babel/preset-typescript`). Babel's strength is its unmatched plugin ecosystem and precise targeting; its weakness is speed (JS-based, single-threaded per file). Modern guidance: keep Babel where its plugins earn their keep, use faster tools elsewhere.

## When to use

- Maintaining CRA-era, Jest, or custom webpack Babel pipelines.
- Custom syntax transforms (Babel plugins for codemods or DSLs).
- Precise browser targeting with `preset-env` + `core-js` polyfills.
- React Native / Metro bundler setups (Babel-based).
- Deciding what stays on Babel vs moves to SWC/esbuild.

## Core concepts

- **Config files.** `babel.config.js` (root, monorepo-wide) vs `.babelrc` (per-package, file-relative). Root config is the modern default; `.babelrc` doesn't apply to files outside its package.
- **`preset-env`.** Compiles based on `targets` (browserslist): only transforms what targets lack. `bugfixes: true` for smaller output; `shippedProposals` for stable proposals.
- **Polyfills.** `core-js` via `useBuiltIns: 'usage'` (inject per-file, needs `corejs` version set) or `'entry'` (whole bundle). `usage` + pinned core-js version = smallest correct output.
- **Plugin ordering.** Plugins run before presets; within, ordering matters (e.g., decorators before class properties). `@babel/plugin-proposal-decorators` `version: '2023-11'` vs legacy — pick deliberately.
- **`env` option.** Different config per `BABEL_ENV`/`NODE_ENV` (test vs development vs production): e.g., istanbul only in test, minification-related plugins only in production.
- **Caching.** `babel-loader` `cacheDirectory: true`; Jest caches transforms. First build is slow; warm cache should be fast — if not, investigate.
- **Writing plugins.** Visitor pattern on the AST (`path.replaceWith`, `path.remove`); `@babel/types` builders; always write tests with `@babel/core` transform snapshots.

## Practical workflow

**1. Baseline config.**
```js
// babel.config.js
module.exports = api => {
  api.cache.using(() => process.env.NODE_ENV);
  const isTest = api.env('test');
  return {
    presets: [
      ['@babel/preset-env', { targets: isTest ? { node: 'current' } : '> 0.5%, not dead', bugfixes: true,
        useBuiltIns: 'usage', corejs: { version: '3.36', proposals: false } }],
      ['@babel/preset-react', { runtime: 'automatic' }],
      '@babel/preset-typescript',
    ],
    plugins: [
      ['@babel/plugin-proposal-decorators', { version: '2023-11' }],
    ],
  };
};
```

**2. Browserslist.** Define targets once (`.browserslistrc` or package.json) — preset-env, Autoprefixer, and eslint all read it. One source of truth.

**3. Test transform.** `npx babel src/index.ts --out-file /tmp/out.js` and inspect: are helpers duplicated per file? (`@babel/plugin-transform-runtime` dedupes helpers via `@babel/runtime` — use it for libraries.)

**4. Library authors.** Use `@babel/plugin-transform-runtime` (no global polyfill pollution) instead of `useBuiltIns: 'usage'` (which pollutes globals — fine for apps, bad for libraries).

**5. Custom plugin (when needed).**
```js
module.exports = () => ({
  visitor: {
    Identifier(path) {
      if (path.node.name === 'DEBUG' && !process.env.DEBUG) path.replaceWith(t.booleanLiteral(false));
    },
  },
});
```
Keep plugins small, pure, and tested — AST transforms are a maintenance liability.

## Common pitfalls

- **Double transpilation.** Babel + TypeScript + bundler each transforming → slow builds and subtle bugs. One TS strip (preset-typescript or tsc), one syntax transform.
- **Helper duplication.** Without transform-runtime, helpers inline per file — bloat in libraries. Apps: fine; libraries: use the runtime.
- **Wrong core-js version.** `corejs: 3` floating vs locked `3.36` — floating changes polyfill behavior between installs. Pin it.
- **Polyfilling libraries.** `useBuiltIns: 'usage'` in a published library pollutes consumers' globals. Libraries use transform-runtime; apps use usage/entry.
- **`.babelrc` vs `babel.config.js` confusion.** `.babelrc` lookup stops at package boundaries — monorepo files outside the package silently get no config. Prefer root `babel.config.js`.
- **Env-specific bugs.** `api.env('test')` branches that change semantics (not just speed) cause "tests pass, prod breaks". Keep env branches to instrumentation/caching.
- **Plugin ordering.** Decorators/class-properties/static-blocks ordering issues produce cryptic errors. Follow the documented order for proposal plugins.
- **Staying on Babel for speed-critical paths.** If Babel is the build bottleneck and no Babel-only plugin is needed, that's the signal to move that step to SWC/esbuild.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…