Webpack 5 Beta + babel-loader: Why do I still have arrow functions?

Webpack 5 Release Update

ecmaVersionwas removed for the release candidate. That said, it’s now possible to describe your target environment to Webpack 5 using output.environment(as mentioned by Prashanth Puranik), which you can learn more about here.

Webpack 5 Beta is out, and if you’ve dipped your toes in, you might’ve noticed that some plugins and loaders aren’t yet compatible with some of the API changes.

This was my assumption with babel-loader a month after building micro frontends (at least 20) when the news came down the pipeline that management was backpedaling and we did in fact have to support IE 11. Cue my surprise when popping open bundles only to discover that some fat arrows were still, um, arrows.

I dug through the v4 to v5 migration docs, forked babel-loader, migrated it to the latest API, then published it to npm with a half-baked name to give it a shot on my work machine. I ran the build, and to my disappointment the results were the same. I sat defeated for a moment in front of an open bundle, when suddenly I realized the ES6 code is actually from webpack.

The Solution

If this week had a hero, it would be evilebottnawi for putting this post out into the ether.

The solution is this:

// webpack.config.js
module.exports = {
  ... webpack config props...
  output: {
    filename: [name]-[contenthash].js,
    ecmaVersion: 5 // <= this is it
  }
}

In Webpack 4, ecmaVersion isn’t an exposed option. When upgrading to Webpack 5, it is, and defaults to output ES6, so ecmaVersion: 5 must be set manually.

Read more about ecmaversion here.

Since I likely won’t be the last person to run into this, here kind stranger, have a Medium article.