Bug Report
Current behavior
The current ways to include regenerator runtime all lead to global scope pollution. That means even in the cases where it is expected to not cause global scope pollution, which is when used with @babel/plugin-transform-runtime with {regenerator: true, corejs: 3} and {regenerator: true, corejs: 2}. I made a reproduction repo that illustrates all the ways that include the regenerator runtime automatically (and the case where it is expected to exist for sake of illustration). All of them cause global scope pollution, mainly because:
var _regenerator = _interopRequireDefault(require("@babel/runtime-corejs3/regenerator"));
var _regenerator = _interopRequireDefault(require("@babel/runtime-corejs2/regenerator"));
var _regenerator = _interopRequireDefault(require("@babel/runtime/regenerator"));
require("regenerator-runtime/runtime");
all require the same:
module.exports = require("regenerator-runtime");.
The regenerator-runtime regenerator.js file, which contains the code below, not only exports but assigns the exported value to window:
try {
regeneratorRuntime = runtime;
} catch (accidentalStrictMode) {
// This module should not be running in strict mode, so the above
// assignment should always work unless something is misconfigured. Just
// in case runtime.js accidentally runs in strict mode, we can escape
// strict mode using a global Function call. This could conceivably fail
// if a Content Security Policy forbids using Function, but in that case
// the proper solution is to fix the accidental strict mode problem. If
// you've misconfigured your bundler to force strict mode and applied a
// CSP to forbid Function, and you're not willing to fix either of those
// problems, please detail your unique predicament in a GitHub issue.
Function("r", "regeneratorRuntime = r")(runtime);
}
This is fine when the global scope pollution is expected, but when its not, it should not do that, like the documentation here says: https://babeljs.io/docs/en/babel-plugin-transform-runtime#regenerator-aliasing
GithubRepo: https://github.com/JMarkoski/babel-regenerator-runtime
Run npm install && npm run build:all , open the .html files in webpack_dist folder in the browser and open the console to see the regenerator runtime object logged.
Expected behavior
When used with @babel/plugin-transform-runtime with {regenerator: true, corejs: 2} or {regenerator: true, corejs: 3} it should not cause global scope pollution.
Environment
System:
OS: Linux 4.15 Ubuntu 18.04.4 LTS (Bionic Beaver)
Binaries:
Node: 10.19.0 - /usr/bin/node
Yarn: 1.22.4 - /usr/bin/yarn
npm: 6.13.4 - /usr/bin/npm
npmPackages:
@babel/cli: ^7.11.6 => 7.11.6
@babel/core: ^7.11.6 => 7.11.6
@babel/plugin-transform-runtime: ^7.11.5 => 7.11.5
@babel/preset-env: ^7.11.5 => 7.11.5
@babel/runtime: ^7.11.2 => 7.11.2
@babel/runtime-corejs3: ^7.11.2 => 7.11.2
webpack: ^4.44.2 => 4.44.2
Possible Solution
To make builtin regenerator runtime analog to builtin core-js features.
Bug Report
Current behavior
The current ways to include regenerator runtime all lead to global scope pollution. That means even in the cases where it is expected to not cause global scope pollution, which is when used with
@babel/plugin-transform-runtimewith{regenerator: true, corejs: 3}and{regenerator: true, corejs: 2}. I made a reproduction repo that illustrates all the ways that include the regenerator runtime automatically (and the case where it is expected to exist for sake of illustration). All of them cause global scope pollution, mainly because:all require the same:
module.exports = require("regenerator-runtime");.The
regenerator-runtimeregenerator.jsfile, which contains the code below, not only exports but assigns the exported value towindow:This is fine when the global scope pollution is expected, but when its not, it should not do that, like the documentation here says: https://babeljs.io/docs/en/babel-plugin-transform-runtime#regenerator-aliasing
GithubRepo: https://github.com/JMarkoski/babel-regenerator-runtime
Run
npm install && npm run build:all, open the.htmlfiles inwebpack_distfolder in the browser and open the console to see the regenerator runtime object logged.Expected behavior
When used with
@babel/plugin-transform-runtimewith{regenerator: true, corejs: 2}or{regenerator: true, corejs: 3}it should not cause global scope pollution.Environment
Possible Solution
To make builtin regenerator runtime analog to builtin core-js features.