Some "exports" are not transpiled to "__webpack_exports__" and cause "ReferenceError: exports is not defined"

[yf-yang]

Link to the code that reproduces this issue

https://github.com/yf-yang/next-14-exports-bug

To Reproduce

git clone git@github.com:yf-yang/next-14-exports-bug.git
cd next-14-exports-bug
pnpm i
cd dep
pnpm compile
cd ../myapp
pnpm dev

Current vs. Expected behavior

The site got an error: "ReferenceError: exports is not defined"

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: 8.10.0
Relevant Packages:
  next: 14.0.5-canary.12
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

SWC transpilation

Additional context

I've located the bug:

in myapp/.next/static/chunks/app/page.js, the generated code of (app-pages-browser)/../dep/build/base.js is:

__webpack_require__.r(__webpack_exports__);
/* harmony import */ var _swc_helpers_class_private_field_get__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! @swc/helpers/_/_class_private_field_get */ "(app-pages-browser)/../node_modules/.pnpm/@swc+helpers@0.5.2/node_modules/@swc/helpers/esm/_class_private_field_get.js");
/* harmony import */ var _swc_helpers_class_private_field_init__WEBPACK_IMPORTED_MODULE_2__ = __webpack_require__(/*! @swc/helpers/_/_class_private_field_init */ "(app-pages-browser)/../node_modules/.pnpm/@swc+helpers@0.5.2/node_modules/@swc/helpers/esm/_class_private_field_init.js");
/* harmony import */ var _swc_helpers_class_private_field_set__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__(/*! @swc/helpers/_/_class_private_field_set */ "(app-pages-browser)/../node_modules/.pnpm/@swc+helpers@0.5.2/node_modules/@swc/helpers/esm/_class_private_field_set.js");




Object.defineProperty(__webpack_exports__, "__esModule", ({
      value: true
}));
function _export(target, all) {
      for(var name in all)Object.defineProperty(target, name, {
          enumerable: true,
          get: all[name]
    });
}
_export(exports, {
      BaseClass: function() {
          return BaseClass;
    },
    BaseClass2: function() {
          return BaseClass2;
    }
});
var _a = /*#__PURE__*/ new WeakMap(), _b = /*#__PURE__*/ new WeakMap();
class BaseClass {
      get a() {
          if ((0,_swc_helpers_class_private_field_get__WEBPACK_IMPORTED_MODULE_0__._)(this, _a) === undefined) {
              (0,_swc_helpers_class_private_field_set__WEBPACK_IMPORTED_MODULE_1__._)(this, _a, 1);
        }
        return (0,_swc_helpers_class_private_field_get__WEBPACK_IMPORTED_MODULE_0__._)(this, _a);
    }
    get b() {
          return (0,_swc_helpers_class_private_field_get__WEBPACK_IMPORTED_MODULE_0__._)(this, _b);
    }
    constructor(){
          (0,_swc_helpers_class_private_field_init__WEBPACK_IMPORTED_MODULE_2__._)(this, _a, {
              writable: true,
              value: void 0
        });
        (0,_swc_helpers_class_private_field_init__WEBPACK_IMPORTED_MODULE_2__._)(this, _b, {
              writable: true,
              value: void 0
        });
        (0,_swc_helpers_class_private_field_set__WEBPACK_IMPORTED_MODULE_1__._)(this, _b, 2);
    }
}
var _a1 = /*#__PURE__*/ new WeakMap(), _b1 = /*#__PURE__*/ new WeakMap();
class BaseClass2 {
      get a() {
          if ((0,_swc_helpers_class_private_field_get__WEBPACK_IMPORTED_MODULE_0__._)(this, _a1) === undefined) {
              (0,_swc_helpers_class_private_field_set__WEBPACK_IMPORTED_MODULE_1__._)(this, _a1, 1);
        }
        return (0,_swc_helpers_class_private_field_get__WEBPACK_IMPORTED_MODULE_0__._)(this, _a1);
    }
    get b() {
          return (0,_swc_helpers_class_private_field_get__WEBPACK_IMPORTED_MODULE_0__._)(this, _b1);
    }
    constructor(){
          (0,_swc_helpers_class_private_field_init__WEBPACK_IMPORTED_MODULE_2__._)(this, _a1, {
              writable: true,
              value: void 0
        });
        (0,_swc_helpers_class_private_field_init__WEBPACK_IMPORTED_MODULE_2__._)(this, _b1, {
              writable: true,
              value: void 0
        });
        (0,_swc_helpers_class_private_field_set__WEBPACK_IMPORTED_MODULE_1__._)(this, _b1, 2);
    }
}

Here, _export(exports, ...) should be transpiled to _export(__webpack_exports__, ...), but it fails to do so.

It seems it only happen when those _swc_helpers_class_private_field_xxxxxx exist, I am not sure that's a bundler bug or swc bug, tag it as swc bug for now.

The bug does not appear in next 13.5.4

[yf-yang]

The javascript code of dep/build/base.js:

"use strict";
Object.defineProperty(exports, "__esModule", {
    value: true
});
function _export(target, all) {
    for(var name in all)Object.defineProperty(target, name, {
        enumerable: true,
        get: all[name]
    });
}
_export(exports, {
    BaseClass: function() {
        return BaseClass;
    },
    BaseClass2: function() {
        return BaseClass2;
    }
});
class BaseClass {
    #a;
    #b;
    constructor(){
        this.#b = 2;
    }
    get a() {
        if (this.#a === undefined) {
            this.#a = 1;
        }
        return this.#a;
    }
    get b() {
        return this.#b;
    }
}
class BaseClass2 {
    #a;
    #b;
    constructor(){
        this.#b = 2;
    }
    get a() {
        if (this.#a === undefined) {
            this.#a = 1;
        }
        return this.#a;
    }
    get b() {
        return this.#b;
    }
}

@kdy1 Would you please take a look? Is it a next-swc bug?

[kdy1]

I cannot reproduce.

> export_bug@0.1.0 dev /Users/kdy1/projects/next-repro-59603/myapp
> next dev

   ▲ Next.js 14.0.5-canary.12
   - Local:        http://localhost:3000

 ✓ Ready in 708ms

[github-actions]

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases. You can also use the GitHub templates (preferred) for App Router and Pages Router, or the CodeSandbox: App Router or CodeSandbox: Pages Router templates to create a reproduction with canary from scratch.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without reproduction steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[kdy1]

Okay I reproduced it.

[kdy1]

It seems it only happen when those _swc_helpers_class_private_field_xxxxxx exist, I am not sure that's a bundler bug or swc bug, tag it as swc bug for now.

I got it. You configured @swc/core to emit common js modules and es2022 target so it still contains problematic syntaxes like private fields in output. But then while next-swc compiles your app to something lower, it injects helpers using import statements because those are modules. Now it has import statements, so it's ESM and webpack ignores exports in the file.

[kdy1]

I uploaded the fix at https://github.com/kdy1/next-repro-59603

[tomtobac]

hey @kdy1, I think this one has the same issue/related: #55430

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.