Smart Deals - promotions, discount codes and sales

babel.config.js Generator

A Babel configuration for modern JavaScript and TypeScript.

Secure (SSL)
Client-Side Processing
100% Free
Instructions
  • 1
    Enter data
    Enter content, paste text or load a file from disk.
  • 2
    Click the button
    The tool will immediately process your data in the browser.
  • 3
    Get the result
    Copy the finished text or save the file to your device.
function runTool() {
  return "Result ready in 0.1s";
}

A list of target environments, for example “> 0.5%, last 2 versions, not dead” or “defaults”.

Set the options and click “Generate config”.

Rate this tool:

Related tools

Other tools you may find useful

babel.config.js generator - a transpilation setup matched to your browsers

The babel.config.js generator assembles a Babel configuration file from the presets you actually need. Type a list of target environments, decide whether the project uses React and TypeScript, and whether it should handle class fields - the result is a ready module.exports with a presets array and a plugins section. Instead of retyping the syntax from memory you get a file that drops straight into the project root.

How Babel differs from just running the code

Babel is a compiler that turns modern JavaScript - ES2015 syntax and newer, JSX, type annotations - into a form the target environment can run. On its own it does not know what to transform: the configuration tells it. Without a settings file Babel passes code through almost untouched, so babel.config.js is where you declare presets and plugins. A preset is a named bundle of transforms; a plugin is a single transform. The same logic drives the other build files - you assemble the repository ignore list in the gitignore generator before the compiler configuration even comes up.

What this tool produces

The output has a fixed shape: presets ordered the way Babel runs them, and plugins with an optional class-fields plugin. The switches add presets, and duplicates are removed.

ItemWhen it enters the fileWhat it does
@babel/preset-envalwaysbrings ES2015+ syntax down to the level in the targets field
@babel/preset-reactwhen you tick Reactprocesses JSX; runtime: 'automatic' removes the React import from every file
@babel/preset-typescriptwhen you tick TypeScriptstrips type annotations without checking them
plugin-proposal-class-propertieswhen you tick class-propertieshandles class fields in loose mode

babel.config.js versus .babelrc

Babel reads configuration from two kinds of file, and the difference is practical rather than cosmetic. babel.config.js is a project-wide configuration: it applies across the whole tree, including code inside node_modules, which matters when a dependency ships untranspiled sources. .babelrc (or .babelrc.json) is file-relative - it works only in its own directory and subdirectories, and Babel stops looking once it meets a package.json. For monorepos and most new projects the project-wide file is recommended, because a single place describes the whole compilation. This tool generates exactly that babel.config.js. You keep the sibling build files next to it in the same root - the webpack configuration or the tsconfig.json file.

Targets, browserslist and output size

The targets field is the heart of preset-env. It decides how many transforms are applied: the newer the environments you name, the less Babel has to rewrite and the smaller and faster the result. You write the value in browserslist syntax - the same one Autoprefixer and other tools use - so a single value steers the whole build chain. A few common values:

defaults
> 0.5%, last 2 versions, not dead
last 2 Chrome versions
node 18

Rather than repeat the list in each tool, it is worth moving it to a browserslist field in package.json or a .browserslistrc file - then preset-env reads it from there and the Babel config stays short. Naming just node 18 tells Babel the code targets a server, not a browser, so most browser transforms disappear.

Polyfills, @babel/runtime and the syntax boundary

Babel transforms syntax by default, not APIs. An arrow function and a class get rewritten, but Promise, Array.prototype.includes or fetch are runtime features - if the environment lacks them, transpilation alone does not help. Missing APIs are supplied by polyfills (once through @babel/polyfill, today through core-js with the useBuiltIns option in preset-env). Duplication is a separate problem: plugins inject the same helper code into every file. The @babel/runtime package together with @babel/plugin-transform-runtime turns those repeats into one shared import - a noticeable saving in a library you publish for others.

How to use the generator

  1. Type targets - this list decides how many transforms preset-env applies.
  2. Tick React if the project uses JSX; the preset gets runtime: 'automatic'.
  3. Tick TypeScript if you write in .ts/.tsx - remember Babel does not check the types.
  4. Leave or clear the class-fields plugin depending on whether you need it.
  5. Click Generate config, save the result as babel.config.js in the project root, then install the listed presets with your package manager.

Frequently asked questions

Does Babel check TypeScript types?

No. @babel/preset-typescript only strips type annotations file by file so that valid JavaScript remains. Type checking stays with the TypeScript compiler (tsc --noEmit) or the editor. This split is deliberate: Babel is fast because it never analyses types across files.

Why runtime: 'automatic' in preset-react?

In automatic mode Babel inserts the JSX helper import itself, so import React from 'react' at the top of every component is no longer needed. The code is shorter and the build raises no unused-import warnings. Classic mode is left only for older React versions.

How does babel.config.js differ from .babelrc?

babel.config.js applies to the whole project, including code in node_modules, and is looked up in the project root. .babelrc applies only within its own directory and subdirectories. For new projects and monorepos the project-wide file is recommended, because a single place describes the whole compilation.

Do I still need Babel with Vite or esbuild?

Usually not for transpilation itself - Vite relies on esbuild, which handles TypeScript and JSX on its own. Babel earns its place when you need a specific plugin (for decorators or a styling library, say) that esbuild lacks, or when you target unusually old browsers. Then the config from this generator plugs into a Babel step alongside the main bundler.

Install Webp.pl Have the tools in your own pocket!