Hey @sodatea! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

As a workaround, you can use https://github.com/tleunen/babel-plugin-module-resolver to alias @babel/runtime -> @babel/runtime-corejs2

@sodatea I have been thinking about this issue today, and I think that the proper solution would be to transpile @babel/runtime's helpers using @babel/plugin-transform-runtime itself.
This is tricky, because we should aboud transpiling everything else except for polyfills, to avoid injecting references to themselves inside the helpers.
A working config might look like this:

module.exports = {
  overrides: [{
    // Use exclude or include, but be sure not to transpile those two packages
    exclude: ["@babel/runtime", "core-js"],

    // Your normal config
    presets: ["@babel/preset-env"],
    plugins: ["@babel/plugin-transform-runtime"]
  }, {
    include: "@babel/runtime",
    
    plugins: [
      ["@babel/plugin-transform-runtime", {
        "helpers": false,
        "corejs": 3
      }]
    ]
  }]
};

I can't believe how hard was to find this. I found here from @vue/babel-preset-app source code.

Basically all I want to do is to:

• Include only necessary polyfills for target environment using @babel/preset-env
• Transform the babel helpers into imports using @babel/plugin-transform-runtime

The problem is that the babel helpers themselves need polyfills when targeting IE 11 for example.

Thanks to this issue & @vue/babel-preset-app source code I somehow managed to get this to work using following configuration:

// babel.config.js
module.exports = {
  sourceType: 'unambiguous',
  overrides: [{
    exclude: [/@babel[\/|\\\\]runtime/],
    presets: [['@babel/preset-env', { useBuiltIns: 'usage', corejs: 3 }]],
    plugins: [
      ['@babel/plugin-transform-runtime', { version: '^7.8.4' }]
    ]
  },
  {
    include: [/@babel[\/|\\\\]runtime/],
    presets: [
      ['@babel/preset-env', {
        useBuiltIns: 'usage',
        corejs: 3
      }]
    ]
  }
  ]
};

// webpack.config.js
module.exports = {
  entry: './src/index.js',
  mode: 'development',
  module: {
    rules: [
      {
        test: /\.m?js$/,
        use: 'babel-loader',
        exclude: file => /node_modules/.test(file) && !/@babel[\/|\\\\]runtime/.test(file)
      }
    ]
  }
};

PLEASE let me know if you know of a better way to achieve this.

Your config looks fine to me: if a dependency (@babel/runtime) uses modern features not supported by your target envs, it should be transpiled.

There were a few problems when transpiling the typeof.js helper from @babel/runtime, but they have been fixed in v7.8.4.

As a personal note, I find this config more explicit:

module.exports = {
  sourceType: 'unambiguous',
  presets: [
    ['@babel/preset-env', {
      useBuiltIns: 'usage',
      corejs: 3
    }]
  ],
  overrides: [{
    exclude: [/@babel[\/|\\\\]runtime/],
    plugins: [
      ['@babel/plugin-transform-runtime', { version: '^7.8.4' }]
    ]
  }]
};

It does the same thing as your config, but makes it explicit that @babel/preset-env is actually applied to every file.

Also, starting from v7.8.4 it's probably safe to transpile @babel/runtime with itself. If it works, this config might be enough:

module.exports = {
  sourceType: 'unambiguous',
  presets: [
    ['@babel/preset-env', {
      useBuiltIns: 'usage',
      corejs: 3
    }]
  ],
  plugins: [
    ['@babel/plugin-transform-runtime', { version: '^7.8.4' }]
  ]
};

@nicolo-ribaudo Alright, thanks for your insights!

I also noticed that when setting useESModules: true on plugin-transform-runtime you can leave the sourceType: 'unambiguous' out. useESModules: true seems to produce a slightly larger bundle than just using sourceType: 'unambiguous' . Which one should I use? Or both?

useESModules: true should provide a smaller output when using Rollup because it handles ES modules better than CJS.
Webpack 5 might have the same benefit because it concatenates ES modules.

However, if you don't use native ES modules it shouldn't make too much a difference anyway.

Did some tests.. I'm using webpack 4. sourceType: 'unambiguous' + useEsModules: true seems to include both helpers/.js and helpers/esm/.js.

So you should probably use sourceType: 'module' + useESModules: true OR sourceType: 'unambiguous' + useESModules: false

@nicolo-ribaudo I did not have any dependencies other than babel/webpack related. See here https://github.com/micopiira/babel-webpack-test

But using sourceType: 'module' + useESModules: true OR sourceType: 'unambiguous' + useESModules: false the helpers are only included once. Only combination of sourceType: 'unambiguous' + useEsModules: true includes them twice.

I'm closing this issue, since it's possible to transpile @babel/runtime with @babel/preset-env to add polyfills.