Babel/core-js URL polyfill breaks Webpack's new URL() for Web Workers

[gregaou]

When @babel/preset-env targets an older browser environment (e.g., chrome >= 52) that lacks native support for the new URL(..., import.meta.url) syntax, it injects a polyfill for the URL constructor from core-js. This polyfilled URL constructor interferes with Webpack's static analysis for Web Workers, which specifically looks for the new URL(...) pattern.

As a result, Webpack fails to create a separate chunk for the worker. Instead, the core-js polyfill is invoked with an incorrect, non-functional path, causing the worker instantiation to fail at runtime.

Environment

• @babel/core: ^7.24.7
• @babel/preset-env: ^7.24.7
• webpack: ^5.91.0
• babel-loader: ^9.1.3
• core-js-pure: ^3.43.0
• babel-plugin-polyfill-corejs3: ^0.12.0

Steps to Reproduce

A full reproduction repository is available here: https://github.com/gregaou/example-babel-polyfill-workers

1. Clone the repository.
2. Ensure the .browserslistrc file targets an older browser:

   chrome >= 52
   

3. Install dependencies (npm install or yarn).
4. Run the build (npm run build or yarn build).
5. Inspect the generated output in dist/.

Expected Behavior

When targeting a modern browser like chrome >= 67 (where new URL(..., import.meta.url) is natively supported), Babel does not polyfill URL. Webpack correctly identifies the syntax and generates a functional worker loader:

// Correct output for modern targets
const newFibWorker = new Worker(new URL(/* worker import */ __webpack_require__.p + __webpack_require__.u("src_worker_ts-_..."), __webpack_require__.b));

This code works as expected.

Actual Behavior

When targeting chrome >= 52, @babel/preset-env injects the core-js polyfill for URL. The resulting code in the bundle looks like this:

// Incorrect output for older targets
const newFibWorker = new Worker(new (core_js_pure_stable_url_index_js__WEBPACK_IMPORTED_MODULE_2___default())('./worker.ts', "file:///.../src/index.tsx"));

This fails at runtime because:

1. The new URL(...) syntax that Webpack's parser looks for has been replaced.
2. The core-js polyfill is invoked with a file-system path (import.meta.url is transpiled to a file path), which is not a valid base for creating a worker URL in the browser.

[ljharb]

Seems like this would happen without a polyfill, too, if someone did const WebURL = URL; new WebURL()?

[zloirock]

core-js and babel-plugin-polyfill-corejs3 work as they should. The issue in integration with webpack - most likely, in babel-loader or in webpack directly - static analysis of this case should happen before transpiling.

[JLHwung]

Well, if webpack analyses URL before Babel-loader, it may not even successfully parse the code if there is JSX, TS or ES proposals.

[gregaou]

Ok, I understand the issue now. Thank you for your answers @JLHwung @zloirock @ljharb, they helped me a lot in grasping the core problem.

To summarize my understanding:
When targeting chrome >= 52 (or similar environments where the URL object might be polyfilled), the URL object gets polyfilled by Babel before Webpack's analysis. As a result, Webpack doesn't recognize the new Worker(new URL(..., import.meta.url)) syntax as intended for worker chunking. This prevents Webpack from producing the correct chunks and handling the import of this part of the code properly.

I'm still not entirely sure on how to fix this properly within the current setup. My initial thought for a potential solution would be to explore if we can add specific Babel rules for these particular worker files to avoid polyfilling "web.url" for them, allowing Webpack to see the original syntax.

Any further insights or suggestions on a robust fix would be greatly appreciated!

[liuxingbaoyu]

A less elegant solution: https://github.com/webpack-contrib/worker-loader
Although it says deprecated, it actually still works in webpack 5. :)