Bug: React DevTools throws ReferenceError: regeneratorRuntime is not defined

[leidegre]

React version: 16.3.1

Steps To Reproduce

1. In the Chrome script debugger, enable "Pause on caught exceptions"
2. Open React DevTools in a app that doesn't use babel or webpack
3. ReferenceError: regeneratorRuntime is not defined

The current behavior

ReferenceError: regeneratorRuntime is not defined

The source of this error seems to be something like this:

try {
  // add if support for Symbol.iterator is present
  __webpack_require__(23)(Yallist);
} catch (er) {}

From chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/react_devtools_backend.js

The expected behavior

No errors are thrown. It's really annoying when React or it's tooling is throwing exceptions because it makes me having to step through a lot of noise when I'm debugging my own stuff. If this could be avoided that would be much appreciated.

---

I get that his might not be fixable and if so, feel free to close but please keep it in mind. Please don't throw exceptions if you absolutely musn't.

[eps1lon]

No errors are thrown.

The code you post catches this error. Are you saying that the code should not have caught exceptions?

I don't find this reasonable to expect. React has a couple of instances where it attempts "something" and catches a potential error. react and react-dom catch "expected errors" in some places as well.

You're essentially demanding that nobody should ever catch errors since that hinders your debug workflow.

[leidegre]

The regeneratorRuntime should not be undefined. I think is a bundling issue.

[eps1lon]

The regeneratorRuntime should not be undefined. I think is a bundling issue.

Then I don't understand why that block would be wrapped in a try-catch

[leidegre]

Okay, so, I don't know what target the React Dev Tools have in mind for browser compatibility but the regeneratorRuntime is something Babel inject to transpile async/await. It can be disabled if you're okay with supporting more modern browsers primarily. For the React Dev Tools that is. And is is webpack configuration.

[kambleaa007]

we can suppress this error, can we?

[bvaughn]

DevTools backend uses the lru-cache package which uses yallist which uses a generator function.

Contributions would be welcome if you'd like to change the Babel config for the extension (and ensure that things still work).

[kambleaa007]

I like to give a try, Fingers crossed
​​​​

[kambleaa007]

react-devtools-extension has webpack.backend.js configured

output: {
    path: __dirname + '/build',
    filename: 'react_devtools_backend.js',
  },

[kambleaa007]

for me its not coming in even catch block

try { // add if support for Symbol.iterator is present __webpack_require__(23)(Yallist); } catch (er) {}

[leidegre]

for me its not coming in even catch block

try { // add if support for Symbol.iterator is present __webpack_require__(23)(Yallist); } catch (er) {}

Note that you have to enable "Pause on caught exceptions" in the script debugger.

[leidegre]

DevTools backend uses the lru-cache package which uses yallist which uses a generator function.

Contributions would be welcome if you'd like to change the Babel config for the extension (and ensure that things still work).

What's the min spec? Is okay to assume a modern browser (with built in support for async/await)?

[kambleaa007]

well, im getting it now,

for me its at,
injectGlobalHook.js file,
chrome-extension://jjeclbmchofefamidmcjnkgaddnpnngm/build/injectGlobalHook.js

module.exports = function (Yallist) {
  Yallist.prototype[Symbol.iterator] = /*#__PURE__*/regeneratorRuntime.mark(function _callee() {
    var walker;

at one place e.stack getting undefined and keep throwing exceptions...

[bvaughn]

What's the min spec? Is okay to assume a modern browser (with built in support for async/await)?

Yes, async/await and generators are supported by all browsers this extension targets (and all semi recent versions of Node that the standalone version targets).

[leidegre]

After some digging around it looks to me that the min spec is actually given by the manifest files in packages\react-devtools-extensions/chrome|edge|firefox/manifest.json which is currently sitting at 49 for Chrome. I think async was added somewhere around 55

But... there are additional targets to consider.

[packages\react-devtools-shared\babel.config.js]:

  if (isTest) {
    targets.node = 'current';
  } else {
    targets.chrome = minChromeVersion.toString();
    targets.firefox = minFirefoxVersion.toString();

    // This targets RN/Hermes.
    targets.ie = '11';
  }

If the lowest common denominator is going to be IE11 due to Hermes then I don't think messing with the targets will help.

It is possible to do things like "exclude": ["transform-regenerator"].

So, this:

return {
    plugins,
    presets: [
      ['@babel/preset-env', {targets}],
      '@babel/preset-react',
      '@babel/preset-flow',
    ],
  };

Changes into...

return {
    plugins,
    presets: [
      ['@babel/preset-env', {targets, exclude: ['transform-regenerator']}],
      '@babel/preset-react',
      '@babel/preset-flow',
    ],
  };

But now I'm uncertain what's going to happen if this code really needs to include a regenerator runtime for Hermes support.

[bvaughn]

After some digging around it looks to me that the min spec is actually given by the manifest files in packages\react-devtools-extensions/chrome|edge|firefox/manifest.json which is currently sitting at 49 for Chrome.

True, although I think this is because we could target that min spec, not because we actually need to (or even care to).

The question about Hermes is a good one though!

We could fork the Babel configs so that the inline and the browser extension packages inject the exclude.

[stale]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[erictheswift]

React Developer Tools 4.10.1 (12/4/2020) — still reproducible

Could it be possible to do conditional check on babel internals to avoid try/catch, e.g.

if (regeneratorRuntime && Symbol.iterator) {
  require('Yallist');
}

?

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[github-actions]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!