Parcel: Disable automatic babel compilation

Created on 17 Apr 2018  路  10Comments  路  Source: parcel-bundler/parcel

Choose one: is this a 馃悰 bug report or 馃檵 feature request?

馃悰 bug report

The site mentions:

Parcel automatically runs these transforms when it finds a configuration file (e.g. .babelrc, .postcssrc) in a module.

But Parcel is automatically running my JS file through babel and "breaking the code" (1. finds await; 2. turns it into regeneratorRuntime; 3. doesn't include regeneratorRuntime)

Does Parcel require a babel configuration or not? The docs make it sounds like one has to install and configure babel-preset-env but apparently it does so without any config.

Moreover, babel-preset-env is still run even if I provide this .babelrc configuration:

{"presets": []}

The only thing that worked:

# .browserlistrc
last 1 Chrome version

馃帥 Configuration (.babelrc, package.json, cli command)

No configuration:

npm run watch
{
  "license": "MIT",
  "scripts": {
    "watch": "parcel index.html"
  },
  "dependencies": {},
  "devDependencies": {
    "parcel-bundler": "^1.7.1"
  }
}

node_modules is clean and up to date. No babel is installed.

馃 Expected Behavior

No babel processing

馃槸 Current Behavior

JS file is transformed by babel from await/async into regeneratorRuntime code.

馃拋 Possible Solution

  • Fix docs; or
  • Disable unconfigured babel

馃敠 Context

馃捇 Code Sample

馃實 Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.6.2
| Node | v9.8.0
| npm/Yarn | 5.8.0
| Operating System | macOS 10.13.4

RFC

Most helpful comment

I had similar problems, and to be honest sometimes I feel like it causes more troubles than it solves. IMO we should only use babel-preset-env if there is a browserlist or similar field in package.json of the project or module. If the user don't ask for await to be transpiled then it should not. This may be resolved by the coming source feature though.

As a workaround you can use last 1 Chrome version as targets.browsers :

  • .babelrc
{
    "presets": [
        ["env", {
            "targets": {
                "browsers": ["last 1 Chrome version"]
            }
        }]
    ]
}

All 10 comments

By default it runs babel-preset-env

There are two issues then:

  1. Docs are incorrect unclear (it does happen automatically "in a module", but what about the current project?)
  2. Custom .babelrc (that excludes any presets) isn't followed

I had similar problems, and to be honest sometimes I feel like it causes more troubles than it solves. IMO we should only use babel-preset-env if there is a browserlist or similar field in package.json of the project or module. If the user don't ask for await to be transpiled then it should not. This may be resolved by the coming source feature though.

As a workaround you can use last 1 Chrome version as targets.browsers :

  • .babelrc
{
    "presets": [
        ["env", {
            "targets": {
                "browsers": ["last 1 Chrome version"]
            }
        }]
    ]
}

Hey guys! Was stuck by this one yesterday while trying to use fast-async instead of transform-regenerator for faster async functions. Looks like parcel doesn't respect project's .babelrc file, as running transforms with babel-cli does the trick.

@kadmil Hit this too.

I'm suggesting using user-defined preset if they defined presets. Don't merge.

This zero config thing is turning out more confusing that it should be, it is not zero config, it is a collection of defaults configs that can be overwritten but we don't know the defaults so we have to dig in the github issues for answers :( maybe just better docs?

Feel free to open a PR or issue with improvement suggestions @psypersky https://github.com/parcel-bundler/website

It transpiles using babel even if there is no .babelrc so this is a bug. The website should not be changed, the bundler should be

This is not a bug, it is a feature and it has been discussed at length. Going to lock this conversation. Please open a new issue if you have an actual bug.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

WayneHiller picture WayneHiller  路  51Comments

garrydzeng picture garrydzeng  路  95Comments

shiloa picture shiloa  路  39Comments

Znarkus picture Znarkus  路  38Comments

v0idifier picture v0idifier  路  51Comments