What's the best practice of babel & core-js?

[liugui]

When I use core-js with babel, I want to try my best to reduce the output file size. So I will configure babel to import only some polyfills. First, I use @babel/preset-env with useBuiltIns: usage like this:

"presets": [
        ["@babel/preset-env", {
            "modules": false,
            "useBuiltIns": "usage",
            "corejs": 3,
            "targets": "ie >= 8"
        }]
  ],

Thanks to core-js and @babel/preset-env, this works well. But I want to use @babel/runtime to import some common helper functions to save more output file size:

"presets": [
        ["@babel/preset-env", {
            "modules": false,
            "useBuiltIns": "usage",
            "corejs": 3,
            "targets": "ie >= 8"
        }]
    ],
    "plugins": [
        ["@babel/plugin-transform-runtime", {
            "corejs": false
        }]
 ]

However, there is a problem: when I use corejs: false in @babel/plugin-transform-runtime, some helper functions may need polyfill which I don't import with useBuiltIns: usage. For example, when I import a helper function : import '@babel/runtime/helpers/asyncToGenerator'; . With the source code of asyncToGenerator, we can see that this helper needs a Promise polyfill:

 if (info.done) {
    resolve(value);
  } else {
   // Here is a Promise
    Promise.resolve(value).then(_next, _throw);
  }
}

However, If my source code doesn't have a Promise function, then the promise polyfill won't be imported. So the runtime function will be broken is some old browsers.

Another way, if I use core-js with @babel/runtime instead of preset-env:

{
    "presets": [
        ["@babel/preset-env", {
            "modules": false,
            "useBuiltIns": "usage",
            "corejs": false,
            "targets": "ie >= 8"
        }]
    ],
    "plugins": [
        ["@babel/plugin-transform-runtime", {
            "corejs": 3
        }]
    ]
}

As we know, @babel/runtime-corejs3 will not only polyfill runtime helpers, but also polyfill my source code. But there is also a big problem: @babel/runtime-corejs3 will ignore the target configure. So it will import all possible polyfills.

So, what's the best practice of babel and core-js? Any help will be appreciated!

[nicolo-ribaudo]

If you want to inject polyfills based on your targets, I recomment compiling @babel/runtime with @babel/preset-env, and not using the corejs option of @babel/plugin-transform-runtime. We made sure that it's always safe to compile @babel/runtime, so it won't cause any problem.

Depending on how you are running Babel, usually this just means not excluding node_modules/@babel/runtime in your bundler config.

[liugui]

Thanks for your reply！ As I described, If I use async function, asyncToGenerator will be imported from @babel/runtime. However, asyncToGenerator needs Promise polyfill. If I don't use any Promise function in my source code, Promise polyfill won't be imported. So it may cause some problem?

Another way, do you mean with node_modules/@babel/runtime included in babel, runtime will be complied together with needed polyfills?

[dosentmatter]

@nyngwang oh yeah, didn't think to check the transpile output for @babel/runtime for some reason, even after I modified my exclusion. I agree that my tests with babel-cli don't make much sense now since I was only transpiling the index.js and not @babel/runtime. I guess I should be able to find the polyfill in the @babel/runtime module of my webpack bundle like you have above.

That makes sense now. Thanks.

[dosentmatter]

@nyngwang what is your webpack config? I noticed that even after not excluding @babel/runtime, I still don't polyfill Promise for ./node_modules/@babel/runtime/helpers/esm/asyncToGenerator.js. I think I know the reason why because I used .babelrc instead of babel.config.json.

Webpack config:

const path = require('path');

module.exports = {
  entry: './index.js',
  module: {
    rules: [{
      test: /\.js$/,
      exclude: {
        and: [/node_modules/],
        not: [/@babel[\\/]runtime/]
      },
      use: [{
        loader: "babel-loader"
      }]
    }]
  },
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist'),
  },
  optimization: {
    minimize: false,
  },
};

Unlike your output, my asyncToGenerator.js has no polyfill for Promise:

(() => {
"use strict";

;// CONCATENATED MODULE: ./node_modules/@babel/runtime/helpers/esm/asyncToGenerator.js
function asyncGeneratorStep(gen, resolve, reject, _next, _throw, key, arg) {
  try {
    var info = gen[key](arg);
    var value = info.value;
  } catch (error) {
    reject(error);
    return;
  }

  if (info.done) {
    resolve(value);
  } else {
    Promise.resolve(value).then(_next, _throw);
  }
}

function _asyncToGenerator(fn) {
  return function () {
    var self = this,
        args = arguments;
    return new Promise(function (resolve, reject) {
      var gen = fn.apply(self, args);

      function _next(value) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, "next", value);
      }

      function _throw(err) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, "throw", err);
      }

      _next(undefined);
    });
  };
}

Now if I rename .babelrc to babel.config.json, it works:

// This entry need to be wrapped in an IIFE because it need to be in strict mode.
(() => {
"use strict";

// EXTERNAL MODULE: ./node_modules/core-js/modules/es.object.to-string.js
var es_object_to_string = __webpack_require__(1539);
// EXTERNAL MODULE: ./node_modules/core-js/modules/es.promise.js
var es_promise = __webpack_require__(8674);
;// CONCATENATED MODULE: ./node_modules/@babel/runtime/helpers/esm/asyncToGenerator.js



function asyncGeneratorStep(gen, resolve, reject, _next, _throw, key, arg) {
  try {
    var info = gen[key](arg);
    var value = info.value;
  } catch (error) {
    reject(error);
    return;
  }

  if (info.done) {
    resolve(value);
  } else {
    Promise.resolve(value).then(_next, _throw);
  }
}

function _asyncToGenerator(fn) {
  return function () {
    var self = this,
        args = arguments;
    return new Promise(function (resolve, reject) {
      var gen = fn.apply(self, args);

      function _next(value) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, "next", value);
      }

      function _throw(err) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, "throw", err);
      }

      _next(undefined);
    });
  };
}

You don't even need webpack to test. You can just use babel directly.

Using .babelrc doesn't have polyfill:

% npx babel ./node_modules/@babel/runtime/helpers/esm/asyncToGenerator.js
function asyncGeneratorStep(gen, resolve, reject, _next, _throw, key, arg) {
  try {
    var info = gen[key](arg);
    var value = info.value;
  } catch (error) {
    reject(error);
    return;
  }

  if (info.done) {
    resolve(value);
  } else {
    Promise.resolve(value).then(_next, _throw);
  }
}

export default function _asyncToGenerator(fn) {
  return function () {
    var self = this,
        args = arguments;
    return new Promise(function (resolve, reject) {
      var gen = fn.apply(self, args);

      function _next(value) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, "next", value);
      }

      function _throw(err) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, "throw", err);
      }

      _next(undefined);
    });
  };
}

Using babel.config.json does have polyfill:

% npx babel ./node_modules/@babel/runtime/helpers/esm/asyncToGenerator.js
"use strict";

require("core-js/modules/es.object.define-property.js");

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports["default"] = _asyncToGenerator;

require("core-js/modules/es.object.to-string.js");

require("core-js/modules/es.promise.js");

function asyncGeneratorStep(gen, resolve, reject, _next, _throw, key, arg) {
  try {
    var info = gen[key](arg);
    var value = info.value;
  } catch (error) {
    reject(error);
    return;
  }

  if (info.done) {
    resolve(value);
  } else {
    Promise.resolve(value).then(_next, _throw);
  }
}

function _asyncToGenerator(fn) {
  return function () {
    var self = this,
        args = arguments;
    return new Promise(function (resolve, reject) {
      var gen = fn.apply(self, args);

      function _next(value) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, "next", value);
      }

      function _throw(err) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, "throw", err);
      }

      _next(undefined);
    });
  };
}

So reason this happens is because of file-relative configuration vs project-wide configuration.

For .babelrc (file-relative config),

Searching will stop once a directory containing a package.json is found, so a relative config only applies within a single package.
The "filename" being compiled must be inside of "babelrcRoots" packages, or else searching will be skipped entirely.
These caveats mean that:

.babelrc.json files only apply to files within their own package
.babelrc.json files in packages that aren't Babel's 'root' are ignored unless you opt in with "babelrcRoots".
Because project-wide config files are separated from the physical location of the config file, they can be ideal for configuration that must apply broadly, even allowing plugins and presets to easily apply to files in node_modules or in symlinked packages, which were traditionally quite painful to configure in Babel 6.x.

So since @babel/runtime is in a separate package and not in babelrcRoots, my .babelrc is never loaded. This is the main thing that tripped me up and caused me to incorrectly think that not excluding @babel/runtime was doing nothing.

So make sure to use a project-wide config if you plan on transpiling things in node_modules based on your babel configuration.

[nyngwang]

So make sure to use a project-wide config if you plan on transpiling things in node_modules based on your babel configuration.

Correct. Here is a related answer: Webpack and Babel not transpiling a dependency inside node_modules that breaks IE 11 and Edge due to ES6's spread syntax.

[liugui]

@nicolo-ribaudo For your reply: Depending on how you are running Babel, usually this just means not excluding node_modules/@babel/runtime in your bundler config.

I tried this:

{
    "presets": [
        ["@babel/preset-env", {
            "modules": false,
            "useBuiltIns": "usage",
            "corejs": 3,
            "targets": "chrome 30",
            "debug": true
        }]
    ],
    "plugins": [
        ["@babel/plugin-transform-runtime", {
            "corejs": false
        }]
    ],
    "only": [
        "./src/*.js",
        "./node_modules/@babel/runtime/**/*.js"
    ]
}

Then I complied with source code:

var a = async () => {

}

const b = {
    c: {
        d: 2
    }
};

console.log(b?.c?.e);

The output is:

import _regeneratorRuntime from "@babel/runtime/regenerator";
import "regenerator-runtime/runtime";
import _asyncToGenerator from "@babel/runtime/helpers/asyncToGenerator";

var _b$c;

var a = /*#__PURE__*/function () {
  var _ref = _asyncToGenerator( /*#__PURE__*/_regeneratorRuntime.mark(function _callee() {
    return _regeneratorRuntime.wrap(function _callee$(_context) {
      while (1) {
        switch (_context.prev = _context.next) {
          case 0:
          case "end":
            return _context.stop();
        }
      }
    }, _callee);
  }));

  return function a() {
    return _ref.apply(this, arguments);
  };
}();

var b = {
  c: {
    d: 2
  }
};
console.log(b === null || b === void 0 ? void 0 : (_b$c = b.c) === null || _b$c === void 0 ? void 0 : _b$c.e);

As we know asyncToGenerator needs Promise polyfill. But the output dosen't import any Promise polyfill. Is there any problem with my config files?

[nicolo-ribaudo]

How are you running Babel?

[kelly-tock]

I too am wondering sometimes what is the best way to set up core-js 3 with the combination of preset-env and babel-runtime, babel-transform-runtime. I feel like this should just be it's own preset or something.

[nicolo-ribaudo]

Babel can only know what features are being used in files that it sees: if your bundler config excludes a file, Babel is not able to check its contents.

[dosentmatter]

Hmm, I was wondering if polyfill-corejs3 special cases @babel/runtime and polyfills based on usage when using usage-global. It would make sense that Babel wouldn't see files if my bundler config excludes a file, but it doesn't seem to be the case from my tests below with babel-cli and webpack-cli. Let me know if I am making a mistake. Here are my findings:

---

Set up:

# install dependencies
$ npm install @babel/core @babel/cli @babel/preset-env babel-plugin-polyfill-corejs3 @babel/plugin-transform-runtime @babel/runtime core-js webpack webpack-cli babel-loader

// index.js
// This will use `@babel/runtime/helpers/asyncToGenerator` and if configuration is correct,
// babel will look at the code in `@babel/runtime/helpers/asyncToGenerator` and polyfill `Promise`
// even though I am not using `Promise` directly in my input source code below.
async function f() {}

---

1. Using babel-cli with @babel/preset-env usage and @babel/transform-runtime
Result: Promise is not polyfilled.
This result is expected based on knowledge of how @babel/preset-env and @babel/transform-runtime works.

{
  "presets": [
    ["@babel/preset-env", {
      "useBuiltIns": "usage",
      "corejs": 3
    }]
  ], // compile JS
  "plugins": [
    "@babel/transform-runtime" // to deduplicate Babel-specific helpers
  ] 
}

% npx babel index.js
"use strict";

var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault");

var _regenerator = _interopRequireDefault(require("@babel/runtime/regenerator"));

var _asyncToGenerator2 = _interopRequireDefault(require("@babel/runtime/helpers/asyncToGenerator"));

function f() {
  return _f.apply(this, arguments);
}

function _f() {
  _f = (0, _asyncToGenerator2["default"])( /*#__PURE__*/_regenerator["default"].mark(function _callee() {
    return _regenerator["default"].wrap(function _callee$(_context) {
      while (1) {
        switch (_context.prev = _context.next) {
          case 0:
          case "end":
            return _context.stop();
        }
      }
    }, _callee);
  }));
  return _f.apply(this, arguments);

---

2. Using babel-cli with babel-plugin-polyfill-corejs3 usage-global
Result: Promise is polyfilled.
This result is a little surprising because I am not using Promise directly in my input source code.
I don't think babel would follow the require() of @babel/runtime/helpers/asyncToGenerator and transpile it
either since it transpiles each file individually.

{
  "presets": ["@babel/preset-env"], // compile JS
  "plugins": [
    ["polyfill-corejs3", { "method": "usage-global" }], // or "polyfill-corejs2", or "polyfill-es-shims"
    "@babel/transform-runtime" // to deduplicate Babel-specific helpers
  ] 
}

% npx babel index.js
"use strict";

var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault");

var _regenerator = _interopRequireDefault(require("@babel/runtime/regenerator"));

var _asyncToGenerator2 = _interopRequireDefault(require("@babel/runtime/helpers/asyncToGenerator"));

require("core-js/modules/es.object.to-string.js");

require("core-js/modules/es.promise.js");

function f() {
  return _f.apply(this, arguments);
}

function _f() {
  _f = (0, _asyncToGenerator2["default"])( /*#__PURE__*/_regenerator["default"].mark(function _callee() {
    return _regenerator["default"].wrap(function _callee$(_context) {
      while (1) {
        switch (_context.prev = _context.next) {
          case 0:
          case "end":
            return _context.stop();
        }
      }
    }, _callee);
  }));
  return _f.apply(this, arguments);
}

---

3. Using webpack-cli with babel-loader exclude (not @babel/runtime), @babel/preset-env usage and @babel/transform-runtime
Result: Promise is not polyfilled.
I expected Promise to be polyfilled because I didn't exclude @babel/runtime.
core-js still doesn't show up (i.e. Promise isn't polyfilled) in the webpack bundle when removing the exclude property completely from webpack.config.js.

{
  "presets": [
    ["@babel/preset-env", {
      "useBuiltIns": "usage",
      "corejs": 3
    }]
  ], // compile JS
  "plugins": [
    "@babel/transform-runtime" // to deduplicate Babel-specific helpers
  ] 
}

const path = require('path');

module.exports = {
  entry: './index.js',
  module: {
    rules: [{
      test: /\.js$/,
      exclude: {
        and: [/node_modules/],
        not: [/@babel[\\/]runtime/]
      },
      use: [{
        loader: "babel-loader"
      }]
    }]
  },
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist'),
  },
  optimization: {
    minimize: false,
  },
};

% npx webpack > /dev/null && grep 'core-js' dist/main.js
# Empty

---

4. Using webpack-cli with babel-loader exclude (not @babel/runtime), babel-plugin-polyfill-corejs3 usage-global
Result: Promise is polyfilled.
This seems to follow case 2 where babel-plugin-polyfill-corejs3 seems to have special handling for @babel/runtime.
core-js still exists (i.e. Promise is polyfilled) in the webpack bundle when removing exclude.not or removing exclude altogether. So exclude doesn't affect whether Promise is polyfilled, making it seem more plausible that babel-plugin-polyfill-corejs3 special cases @babel/runtime.

{
  "presets": ["@babel/preset-env"], // compile JS
  "plugins": [
    ["polyfill-corejs3", { "method": "usage-global" }], // or "polyfill-corejs2", or "polyfill-es-shims"
    "@babel/transform-runtime" // to deduplicate Babel-specific helpers
  ] 
}

const path = require('path');

module.exports = {
  entry: './index.js',
  module: {
    rules: [{
      test: /\.js$/,
      exclude: {
        and: [/node_modules/],
        not: [/@babel[\\/]runtime/]
      },
      use: [{
        loader: "babel-loader"
      }]
    }]
  },
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist'),
  },
  optimization: {
    minimize: false,
  },
};

% npx webpack > /dev/null && grep 'core-js' dist/main.js 
// https://github.com/zloirock/core-js/issues/86#issuecomment-115759028
// this helper broken in `core-js@3.4.1-3.4.4`, so we can't use `shared` helper
  // browsers with MutationObserver, except iOS - https://github.com/zloirock/core-js/issues/339
  // also except WebOS Webkit https://github.com/zloirock/core-js/issues/898
var SHARED = '__core-js_shared__';
  license: 'https://github.com/zloirock/core-js/blob/v3.21.1/LICENSE',
  source: 'https://github.com/zloirock/core-js'
  // except iOS - https://github.com/zloirock/core-js/issues/624
  // https://github.com/zloirock/core-js/issues/679
      // https://github.com/zloirock/core-js/issues/640

I think the polyfill happens in this piece of code:

$({
  global: true,
  wrap: true,
  forced: FORCED
}, {
  Promise: PromiseConstructor
});

---

Conclusion:

Desired result:

• I want to transform my code to my target environment
• I want to add polyfills automatically in my code (not caring about polluting the global namespace) for my input source code and @babel/runtime based on usage. An example requirement is that Promise should be polyfilled when using async, even if I am not using Promise directly in my input source code.
• I want the babel runtime helpers to be re-used via imports (without repetition of babel helpers in each file)

It seems like when using webpack with babel-loader, the only way to achieve my desired result is to use case 4. I have to use babel-plugin-polyfill-corejs3 usage-global. It doesn't matter what or how I exclude or whether I exclude at all in my webpack config for babel-loader. It seems like babel-plugin-polyfill-corejs3 usage-global handles @babel/runtime in a special way.

Note: I tested with core-js@2 and babel-plugin-polyfill-corejs2 usage-global, but it doesn't seem to polyfill Promise for @babel/runtime when using async - neither when using babel-cli or webpack-cli. So It seems the special polyfill handling of @babel/runtime is only for core-js@3.

[dosentmatter]

@nyngwang, I think you might be right about Promise being added because I am using async. I think that didn't use to be the case with just @babe/preset-env and @babel/transform-runtime. I based my example off of this article, where Promise is not polyfilled, even when you use async. I didn't test to confirm the article was correct though.

I guess I made a mistake on the reasoning of why Promise is showing up. It might be showing up because I am using async. In the article, it said that Promise used to not be polyfilled when you used async. In fact, I recently learned that Promise can be polyfilled as a dependency on other things like AsyncIterators. Maybe with the old @babe/preset-env and @babel/transform-runtime Promise wasn't a dependency of async?

But everything I posted was just a guess. I never said I was correct. I wasn't arguing anything. I was merely just posting my findings and my guess at why it could be happening. I was using "seem" multiple times. In fact, I said:

Let me know if I am making a mistake

I suggest that you change your tone of typing a little to sound less confrontational as it is hard to read people's tone of voice through text.

I am okay with reading source code, but it's not feasible to read all third party source code before I use them. And I don't think it is a requirement for me to read the source code if I was just experimenting at a surface level. Again, I was just posting my findings and asking a question. If we all read and understood the source code, we wouldn't be in this discussion.

So if you read the source code, what do you make of it? How do we deal with polyfills that @babel/runtime requires that our application possibly doesn't?
EDIT: Nevermind, I saw your other post. Should be able to just not exclude @babel/runtime.

[dosentmatter]

@nyngwang, no need to apologize. I appreciate you for being considerate.

It makes sense now. I looked at the webpack bundle and babel output and confirmed that @babel/runtime is being checked for polyfills when I don't exclude it. My mistake that caused my confusion was because I was using .babelrc instead of babel.config.json.

I guess I also mistakenly believed that async wasn't causing Promise to be polyfilled. It seems like babel-plugin-polyfill-corejs3 usage-global polyfills Promise when using async (case 2 and 4). However,@babel/preset-env usage doesn't polyfill Promise when using async (case 1 and 3), which seems to follow what is mentioned in the article.

Thanks for the explanation!

[nyngwang]

@dosentmatter While it's a bit too late, I will try to explain what you observed in your 2nd point. Given the babel.config.json/babelrc.json you provided:

{
  "presets": ["@babel/preset-env"],
  "plugins": [
    ["polyfill-corejs3", { "method": "usage-global" }],
    "@babel/transform-runtime"
  ] 
}

The polyfill-corejs3 will be applied first. So any inlined usage of Promise will trigger polyfill-corejs3 to insert global polyfills before it will be replaced by a function of @babel/transform-runtime later.

[cpphen]

What is the point of using something like core-js with @babel/core. Don't they both do the same thing conceptually?

[nicolo-ribaudo]

Babel is normally used for running new syntax in older environments, while core-js (and polyfills in general) is for using new built-in functions in older environments.