Issues creating WebPack Chunks and React LazyLoading

[mustik22]

Recently upgrading to the latest version of babel (7.5) has resulted in the chunk creation behavior in Webpack to change. Subsequently downgrading to @babel/preset-env to 7.4.5 and @babel/register to 7.4.5 resolved the problem. Webpack version 4.38.

Basically I am creating multiple chunks using the LazyLoading feature of react. This feature has been working very well up to this point.

In React something like ..
const { default: module } = await import(/* webpackChunkName: "Ace" */ 'react-ace')

Would create
vendorsAce.js 1.61 MiB vendorsAce [emitted] vendors~Ace

The failure is that this particular output module as well as a few others are not created, and all vendor code (node_modules) is loaded into the 'vendors~bundle.js' file.

vendorsbundle.css 575 KiB vendorsbundle [emitted] vendorsbundle
vendorsbundle.js 9 MiB vendorsbundle [emitted] vendorsbundle

I have isolated the issue to those two babel modules. Rebuilding the node_modules (yarn install) and then downgrading those two modules resolves the issue.

Relevent Webpack configuration
(happy to provide the full file)
output: {
path: DIST_DIR,
filename: 'bundle.js', // Single file node
chunkFilename: '[name].js',
publicPath: '/dist/', // for 'Hot' Module Replacement (HMR), images
},

There is a similar config for JSX files ...
{
test: /.js?$/,
exclude: /node_modules/,
exclude: /geoLocation.js$/,
loader: 'babel-loader',
query: {
presets: [

                        ['@babel/preset-env',
                            {
                                "modules": "commonjs",
                            }
                        ],

                        ['@babel/preset-react',
                            {
                                "development": true
                            }
                        ]

                    ],
                    "plugins": 
                    [
                        "@babel/plugin-transform-react-jsx", 
                        "@babel/plugin-transform-react-jsx-source",
                        "@babel/plugin-proposal-class-properties",
                        "@babel/plugin-syntax-dynamic-import"
                    ],

                    compact: true,
                    cacheDirectory: true

                },
            },

.babelrc
{
"presets": ["@babel/preset-env", "@babel/preset-react"]
"plugins": ["@babel/plugin-syntax-dynamic-import"]
}

Package.json
Can be provided, but it only displays the target versions, not the actual. I got the actual versions from the yarn.lock file (included).

Environment
Mac OS
Visual Studio Code C#, React

Possible Solution
Downgrade @babel/preset-env to 7.4.5 and @babel/register to 7.4.5

Thank you in advance.

yarn.lock.zip

[babel-bot]

Hey @mustik22! 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.

[nicolo-ribaudo]

Why are you transpiling modules to commonjs? You should let webpack handle them, so that it can properly split your bundle.

[mustik22]

As you know Webpack scripts evolve over time, approaches (and work arounds) work in one version but are left in even as the excellent babel and Webpack products evolve.

That being said, when I remove that from the script, I get a significant number of errors in the log (such as) ...
ModuleConcatenation bailout: Cannot concat with /.../Projects/node_modules/@aspnet/signalr/dist/esm/Errors.js because of /.../Projects/node_modules/@aspnet/signalr/dist/esm/NodeHttpClient.js

I am sure I added it (at the time) as a reasonable resolution to a problem that I had. Any alternative suggestions would be greatly appreciated.

[smparsons]

I think I'm having a similar issue. For me after I upgrade @babel/core to 7.5.5, code splitting and dynamic importing breaks. The difference for me is I just have to downgrade @babel/core to 7.5.4 in order for the problem to go away, I don't have to downgrade @babel/preset-env or @babel/register. I know that's not a whole lot to go off of, but any ideas? I'm using webpack version 4.38.

[JLHwung]

@smparsons The OP's issue is that setting modules: "commonjs" will render webpack code splitting useless, although the behavior is expected.

If you don't have a similar configuration, please file a new issue and attach your webpack configuration and package lock files.

[smparsons]

@JLHwung Actually I have modules set to commonjs in my @babel/preset-env configuration too. Just so I understand, why does that render code splitting useless?

[mustik22]

And why did the behavior recently change?

[JLHwung]

In babel/preset-env 7.5, we have enabled proposal-dynamic-import transformer. If you specified modules: commonjs, it will transpile import("foo") roughly to Promise.then(require("foo")) . However, Webpack relies on import() syntax to create an ImportContextDependency, therefore, the code splitting will fail.

Code splitting works since the transformer is not included by default before 7.5.0

It is not recommended to use modules: "commonjs" with Webpack. Not only code splitting will fail but tree shaking would also fail since Webpack relies on static import to knock out useless modules/functions. If you are using babel-loader with Webpack, please specify modules: false and leave the package bundler to analyze the dependencies.

{
  presets: [["@babel/preset-env", { modules: false }]]
}

[smparsons]

@JLHwung Interesting, thanks for the explanation.

[mustik22]

Thank you! That seems to have resolved the problem.

I also changed concatenateModules: false in webpack, that got rid of most the ModuleConcatenation bailout: failures.