Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global variable is not defined in babel 6 / webpack 3 #363

Closed
lerayne opened this issue Nov 20, 2018 · 6 comments
Closed

Global variable is not defined in babel 6 / webpack 3 #363

lerayne opened this issue Nov 20, 2018 · 6 comments
Assignees

Comments

@lerayne
Copy link

lerayne commented Nov 20, 2018

I'm using babel v6.26.3 and webpack 3.12.0

If I call regenerrator-runtime as import 'regenerator-runtime/runtime' to define a global variable the code results to be
START

/***/ "./node_modules/regenerator-runtime/runtime.js":
/***/ (function(module, exports, __webpack_require__) {

/**
 * Copyright (c) 2014-present, Facebook, Inc.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */

var regeneratorRuntime = (function (exports) {
  "use strict";

  var Op = Object.prototype;

END

  // Regardless of whether this script is executing as a CommonJS module
  // or not, return the runtime object so that we can declare the variable
  // regeneratorRuntime in the outer scope, which allows this module to be
  // injected easily by `bin/regenerator --include-runtime script.js`.
  return exports;

}(
  // If this script is executing as a CommonJS module, use module.exports
  // as the regeneratorRuntime namespace. Otherwise create a new empty
  // object. Either way, the resulting object will be used to initialize
  // the regeneratorRuntime variable at the top of this file.
   true ? module.exports : {}
));


/***/ }),

Which means "regeneratorRuntime" is never registered as a global variable and the code stops to work.

This is happening in 0.13.1, I moved to 0.12.1 and everything is working fine there.

@lerayne lerayne changed the title Global variable is not defined in babel 6 Global variable is not defined in babel 6 / webpack 3 Nov 20, 2018
@benjamn
Copy link
Collaborator

benjamn commented Nov 20, 2018

See #353. With [email protected], the global regeneratorRuntime variable is no longer automatically created (unless you evaluate the runtime code in global scope, rather than a Webpack wrapper), but you can import the runtime and define the variable globally yourself.

This is all handled for you if you use @babel/plugin-transform-runtime, by the way. Any file that needs regeneratorRuntime imports it from @babel/runtime/regenerator.

@lerayne
Copy link
Author

lerayne commented Nov 21, 2018

Then probably this readme file should be changed accordingly: https://github.com/facebook/regenerator/blob/master/packages/regenerator-runtime/README.md

It also goes to npm page of the regenerator-runtime and gets people like me confused

@mattjohnsonpint
Copy link

This appears to also breaks Jest tests. Per these docs, one is supposed to add regenerator-runtime (not @babel/plugin-transform-runtime), but it expects regeneratorRuntime to be on the global scope.

Tests fail with ReferenceError: regeneratorRuntime is not defined after updating regenerator-runtime to 0.13.1.

Tried with both Jest version 23.6.0 and 24.0.0-alpha.9.

@vincro
Copy link

vincro commented Jan 3, 2019

Tried with both Jest version 23.6.0 and 24.0.0-alpha.9.

Per chance, did you happen to figure out a fix for this besides a downgrade?

Thanks.

@mattjohnsonpint
Copy link

@vincro - nope. I've set "regenerator-runtime": "0.12.1" in my package.json for now.

@benjamn benjamn self-assigned this Mar 7, 2019
benjamn added a commit that referenced this issue Mar 7, 2019
In #353, I simplified the implementation of regenerator-runtime by
converting runtime.js to a normal CommonJS module. No more global object
detection, and no more sneaky capture/deletion of regeneratorRuntime.

Unfortunately, folks who use only @babel/polyfill and not
@babel/transform-runtime may have existing code that relies on a global
regeneratorRuntime variable. That code will eventually disappear
(:crossed-fingers:), but in the meantime we can continue supporting it by
simply ensuring that regeneratorRuntime is defined globally as a
side-effect of importing regenerator-runtime.

This turns out to be much easier than detecting the global object, as long
as runtime.js runs as a non-strict CommonJS module. See my code comments
for another fallback solution that should cover all remaining cases.

Background discussion:
babel/babel#7646 (comment)

Fixes #363.
Fixes #337.
Fixes #367.
benjamn added a commit that referenced this issue Mar 7, 2019
* Define regeneratorRuntime globally as a side-effect, again.

In #353, I simplified the implementation of regenerator-runtime by
converting runtime.js to a normal CommonJS module. No more global object
detection, and no more sneaky capture/deletion of regeneratorRuntime.

Unfortunately, folks who use only @babel/polyfill and not
@babel/transform-runtime may have existing code that relies on a global
regeneratorRuntime variable. That code will eventually disappear
(:crossed_fingers:), but in the meantime we can continue supporting it by
simply ensuring that regeneratorRuntime is defined globally as a
side-effect of importing regenerator-runtime.

This turns out to be much easier than detecting the global object, as long
as runtime.js runs as a non-strict CommonJS module. See my code comments
for another fallback solution that should cover all remaining cases.

Background discussion:
babel/babel#7646 (comment)

Fixes #363.
Fixes #337.
Fixes #367.

* Update regenerator/package-lock.json.

* Fix Travis CI tests by running `npm i` instead of `npm ci`.

* Prevent Travis from running `npm ci` by default.
@xjamundx
Copy link

xjamundx commented Mar 19, 2019

Ouch, yeah many outdated docs on this in the world. Just got bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants