Inconsistency in Webpack outputs using "eval" and helper runtime function

**I'm submitting a bug report**

**Webpack Version:**
4.39.1

**Babel Core Version**:
7.5.5

**Babel Loader Version**:
8.0.6

**Please tell us about your environment:**
Debian GNU/Linux 8 (jessie)

**Current behavior:**

I'm facing a weird behavior with Webpack and Babel Loader plugin. Using `eval` or `window.eval` with a Babel runtime helper do not produce the same output in production mode.
I think it's a bug because of inconsitancy outputs... (see below) but maybe I'm wrong or it's a bug from Webpack itself.

Run Webpack in production mode with this code that uses a `typeof` and an `eval` (see configurations below)

```
window.f = (o) => {
if (typeof o !== 'object') return eval(o);
};
```

Output:

```
!function(e){var t={};function _(o){if(t[o])return t[o].exports;var r=t[o]={i:o,l:!1,exports:{}};return e[o].call(r.exports,r,r.exports,_),r.l=!0,r.exports}_.m=e,_.c=t,_.d=function(e,t,o){_.o(e,t)||Object.defineProperty(e,t,{enumerable:!0,get:o})},_.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},_.t=function(e,t){if(1&t&&(e=_(e)),8&t)return e;if(4&t&&"object"==typeof e&&e&&e.__esModule)return e;var o=Object.create(null);if(_.r(o),Object.defineProperty(o,"default",{enumerable:!0,value:e}),2&t&&"string"!=typeof e)for(var r in e)_.d(o,r,function(t){return e[t]}.bind(null,r));return o},_.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return _.d(t,"a",t),t},_.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},_.p="",_(_.s=1)}([function(e,t){function _(e){return(_="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(e){return typeof e}:function(e){return e&&"function"==typeof Symbol&&e.constructor===Symbol&&e!==Symbol.prototype?"symbol":typeof e})(e)}function o(t){return"function"==typeof Symbol&&"symbol"===_(Symbol.iterator)?e.exports=o=function(e){return _(e)}:e.exports=o=function(e){return e&&"function"==typeof Symbol&&e.constructor===Symbol&&e!==Symbol.prototype?"symbol":_(e)},o(t)}e.exports=o},function(module,__webpack_exports__,__webpack_require__){"use strict";__webpack_require__.r(__webpack_exports__);var _var_www_test_webpack_eval_node_modules_babel_runtime_helpers_typeof__WEBPACK_IMPORTED_MODULE_0__=__webpack_require__(0),_var_www_test_webpack_eval_node_modules_babel_runtime_helpers_typeof__WEBPACK_IMPORTED_MODULE_0___default=__webpack_require__.n(_var_www_test_webpack_eval_node_modules_babel_runtime_helpers_typeof__WEBPACK_IMPORTED_MODULE_0__);window.f=function(o){if("object"!==_var_www_test_webpack_eval_node_modules_babel_runtime_helpers_typeof__WEBPACK_IMPORTED_MODULE_0___default()(o))return eval(o)}}]);
```

==> The Babel runtime helper for "typeof" isrequired and stored in a variable that contains the full path where is located the helper: "_var_www_test_webpack_eval_node_modules_babel_runtime_helpers_typeof__WEBPACK_IMPORTED_MODULE_0__" (because I'm using the **absoluteRuntime** option I guess).
Also, `__webpack_exports__` and `__webpack_require__` seems to not be handled and minified by Webpack.

**Expected/desired behavior:**

If `eval` is replaced by `window.eval`, the output seems to be OK (no longer __webpack_exports__ / __webpack_require__ or variable with full path) :

```
!function(t){var o={};function e(n){if(o[n])return o[n].exports;var r=o[n]={i:n,l:!1,exports:{}};return t[n].call(r.exports,r,r.exports,e),r.l=!0,r.exports}e.m=t,e.c=o,e.d=function(t,o,n){e.o(t,o)||Object.defineProperty(t,o,{enumerable:!0,get:n})},e.r=function(t){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(t,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(t,"__esModule",{value:!0})},e.t=function(t,o){if(1&o&&(t=e(t)),8&o)return t;if(4&o&&"object"==typeof t&&t&&t.__esModule)return t;var n=Object.create(null);if(e.r(n),Object.defineProperty(n,"default",{enumerable:!0,value:t}),2&o&&"string"!=typeof t)for(var r in t)e.d(n,r,function(o){return t[o]}.bind(null,r));return n},e.n=function(t){var o=t&&t.__esModule?function(){return t.default}:function(){return t};return e.d(o,"a",o),o},e.o=function(t,o){return Object.prototype.hasOwnProperty.call(t,o)},e.p="",e(e.s=1)}([function(t,o){function e(t){return(e="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(t){return typeof t}:function(t){return t&&"function"==typeof Symbol&&t.constructor===Symbol&&t!==Symbol.prototype?"symbol":typeof t})(t)}function n(o){return"function"==typeof Symbol&&"symbol"===e(Symbol.iterator)?t.exports=n=function(t){return e(t)}:t.exports=n=function(t){return t&&"function"==typeof Symbol&&t.constructor===Symbol&&t!==Symbol.prototype?"symbol":e(t)},n(o)}t.exports=n},function(t,o,e){"use strict";e.r(o);var n=e(0),r=e.n(n);window.f=function(t){if("object"!==r()(t))return window.eval(t)}}]);
```

Here is a Gist with Babel & Webpack configuration files: https://gist.github.com/lneveu/b67f5ddcbbfe9330a8bae8a3d360280b

Thanks!

Start with the Webpack and Babel configuration files in the linked Gist, then reproduce the production builds for eval and window.eval. Compare how the Babel runtime helper and Webpack-generated identifiers are emitted; done means identifying whether babel-loader or Webpack owns the inconsistency and adding a focused regression test if the repository provides a suitable test entry point.

Written by the indexing model from the issue text.