exports + Object reference cause breaking Babel transformation

[exogen]

Bug report

Describe the bug

This is a weird one. I suspect it may be due to broken Babel releases upstream, but is still not fixed. It may have something to do with Next.js’ @babel/runtime setup; even if it’s purely a Babel bug we can at least track it here.

To Reproduce

Try creating this component in a project:

const React = require("react");

function BrokenComponent() {
  Object.assign({});
  return React.createElement("p", {}, "Hello");
}

exports.__esModule = true;
exports.default = BrokenComponent;

This is not how I write my code, but rather mimics approximately what Babel does when it transpiles the module (there will also be a few helper functions it generates, but they weren't necessary to reproduce). To be clear: I am writing my components normally with ESM imports and JSX, in a separate package, but when I use the transpiled output of that package in my Next.js app, it triggers this issue.

Then try to use that component in a Next.js page, either via import or require:

const ProblemComponent = require('../ProblemComponent').default;

You’ll either get an import error (no default export, if using import), or:

Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

(if using require, the default property will just be undefined and there will be no error until rendering is attempted)

Commenting out the Object.assign line makes it start working. Somehow the combination of exports + Object triggers a @babel/runtime related transformation?

Expected behavior

The component is imported successfully.

System information

• Version of Next.js: 9.0.2

Additional context

• If the exports references are changed to module.exports, it works. Maybe the transpiled output references the wrong exports object?

The module looks like this in the .next/server output of the page:

/***/ "VjCp":
/***/ (function(module, __webpack_exports__, __webpack_require__) {

"use strict";
__webpack_require__.r(__webpack_exports__);
/* harmony import */ var _babel_runtime_corejs2_core_js_object_assign__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__("UXZV");
/* harmony import */ var _babel_runtime_corejs2_core_js_object_assign__WEBPACK_IMPORTED_MODULE_0___default = /*#__PURE__*/__webpack_require__.n(_babel_runtime_corejs2_core_js_object_assign__WEBPACK_IMPORTED_MODULE_0__);


var React = __webpack_require__("cDcd");

function BrokenComponent() {
  _babel_runtime_corejs2_core_js_object_assign__WEBPACK_IMPORTED_MODULE_0___default()({});

  return React.createElement("p", {}, "Hello");
}

exports.__esModule = true;
exports["default"] = BrokenComponent;

/***/ }),

Note the Object reference became _babel_runtime_corejs2_core_js_object_assign__WEBPACK_IMPORTED_MODULE_0___default.

Note also that the arg name is __webpack_exports__, but the assignments are still to exports. Should it have transformed those assignments to __webpack_exports__? Maybe it's a webpack issue, not Babel?

[exogen]

Interestingly, looking at the .next/server output with Object.assign({}) commented out (which makes it start working), the __webpack_exports__ argument is named exports instead.

So the issue does seem to be that exports becomes the wrong reference.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.