Plugin-transform-runtime can't work without 'exclude: /node_modules/\/'

[jiladahe1997]

Webpack Version: 4.25.1

Babel Core Version: 7.1.5

Babel Loader Version: 8.0.4

Please tell us about your environment: OSX 10.x

Current behavior: When I use babel-loader with @babel/plugin-transform-runtime in webpack. And I just forget to add 'exclude: /node_modules//' in my webpack.config.js, then my code has something wrong:

if I add 'exclude: /node_modules//' in webpack.config.js the problem will disappear.

I notice that :

babel-loader is slow! Make sure you are transforming as few files as possible. Because you are probably matching /.m?js$/, you might be transforming the node_modules folder or other unwanted source.

I have searched everywhere, and I found this: https://stackoverflow.com/questions/43222249/webpack-2-3-3-typeerror-export-is-not-a-function

I think exclude the directory node_modules/ can speed up the babel-loader, but even if I include it, babel-loader and plugin-transform-runtime can still work properly.

Expected/desired behavior:

plugin-transform-runtime can work without 'exclude: /node_modules//'

Here is my webpack.config.js:

const path = require('path')
var webpack = require('webpack')

const processHandle = (percentage, message, ...args) => {
    // console.log(percentage)
  }

module.exports = {
    entry: {
        app: './src/index.js'
    },
    output: {
        path: path.resolve(__dirname, 'build'),
        filename: '[name].js'
    },
    devServer: {
        port: 9000,
        contentBase: path.join(__dirname, 'build')
    },
    mode: "development",
    module: {
        rules: [
            {
                test: /\.js$/,
                use: {
                    loader: 'babel-loader',
                    options: {
                        presets: ['@babel/preset-env','@babel/preset-react'],
                        plugins: ['@babel/plugin-transform-runtime']
                    }
                },
                // exclude: /node_modules\//
            },
            {
                test: /\.css$/,
                use: [
                    {
                        loader: 'style-loader'
                    },
                    {
                        loader: 'css-loader',
                        options: {
                            module: true
                        }
                    }
                ]
            }
        ]      
    },
    plugins: [
        new webpack.ProgressPlugin(processHandle)
    ]
}

I am not sure that's a bug or there is something wrong with my code. Thanks for reading.

[nicolo-ribaudo]

It can work without excluding node_modules, but you have to specify the proper sourceType for each file (often unambiguois work for everything) so that Babel knows which files are modules and which are scripts.

[jiladahe1997]

@nicolo-ribaudo
Thanks for your reply, That's a proper solution. But I still don't understand why if I include node_modules, there will be problems with my code. Does babel-loader or plugin-transform-runtime do anything to node_modules?

[roman-16]

It works for me when I exclude @babel/runtime

[nicolo-ribaudo]

@wa4-fearless-otter I suggest also excluding core-js if you are using it.

[roman-16]

@nicolo-ribaudo I don't quite get it, why do I have to do this?

[nicolo-ribaudo]

Sorry, I meant "if you are injecting core-js either with @babel/plugin-transform-runtime's corejs option or with @babel/preset-env's useBuiltIns, then it's safer to add it to your excludes option".

This is because, as @babel/runtime might break when transpiled because it introduces circular dependencies, core-js might break when transpiled because Babel would try to polyfill its feature detection logic.

e.g. Suppose that a core-js polyfill looks like this:

// object/assign.js

module.exports = Object.assign || function (...) {};

If transpiled, it might become something like this:

// object/assign.js

module.exports = require("object/assign.js") || function (...) {};

[roman-16]

Thanks, that makes sense. But does @babel/runtime still get polyfilled if I exclude both, core-js and @babel/runtime?