i.createSuper is not a function swc error with parcel build

[jeffpeck10x]

🐛 bug report

Using parcel@2.2.1, this happens when I parcel build and then serve the dist directory:

buffer.js:40 Uncaught TypeError: i.createSuper is not a function
    at buffer.js:40:16
    at Object.craGz.@swc/helpers (buffer.js:40:16)
    at l (index.912d6b48.js:1:708)
    at f (index.912d6b48.js:1:812)
    at Object.c7ssz.@swc/helpers (texture.js:6:1)
    at l (index.912d6b48.js:1:708)
    at f (index.912d6b48.js:1:812)
    at Object.bsSjr.@swc/helpers (texture-2d.js:3:1)
    at l (index.912d6b48.js:1:708)
    at f (index.912d6b48.js:1:812)

I have recently updated several packages, so I cannot be 100% sure that this is related to the latest parcel update, but I am posting it here in case anybody else has noticed something similar and can concur.

I am still able to parcel serve without issue.

But, parcel build src/index.html --no-cache --no-scope-hoist --public-url ./ will produce code that will yield the above error.

🎛 Configuration (.babelrc, package.json, cli command)

.parcelrc:

{
  "extends": "@parcel/config-default",
  "transformers": {
    "*.svg": ["...", "@parcel/transformer-inline-string"],
    "*.{js,mjs,jsx,cjs,ts,tsx}": [
      "@parcel/transformer-js",
      "@parcel/transformer-react-refresh-wrap"
    ]
  }
}

babel.config.json (only being used for jest, but posting it here anyway)

{
  "plugins": [
    "@parcel/babel-plugin-transform-runtime",
    ["inline-svg", { "disableSVGO": true }],
    "glsl"
  ],
  "presets": ["@parcel/babel-preset-env", "@babel/preset-typescript"]
}

I don't want to post my whole package.json, but this is a monorepo and I have "@swc/helpers": "^0.3.2" in the package.json of the repo that I am building, and "parcel": "^2.2.1" in the base of the monorepo. This was all working when I was on "parcel": "^2.0.0-rc.0". Like mentioned above, I updated many things at once, so I am not clear if is parcel or something else.

I also have these plugins:

    "@parcel/babel-plugin-transform-runtime": "^2.2.1",
    "@parcel/babel-preset-env": "^2.2.1",
    "@parcel/transformer-glsl": "^2.2.1",
    "@parcel/transformer-inline": "^2.2.1",
    "@parcel/transformer-inline-string": "^2.2.1",

🤔 Expected Behavior

parcel build should produce error-free js when parcel serve works.

😯 Current Behavior

buffer.js:40 Uncaught TypeError: i.createSuper is not a function

💁 Possible Solution

🔦 Context

💻 Code Sample

🌍 Your Environment

Software	Version(s)
Parcel	2.2.1
Node	v14.17.3
npm/Yarn	1.22.17
Operating System	MacOS 11.6.2

[jeffpeck10x]

Confirmed. Downgrading to "parcel": "2.0.0-rc.0", resolves the error.

Specifically this:

    "@parcel/babel-plugin-transform-runtime": "2.0.0-rc.0",
    "@parcel/babel-preset-env": "2.0.0-rc.0",
    "@parcel/transformer-glsl": "2.0.0-rc.0",
    "@parcel/transformer-inline": "2.0.0-rc.0",
    "@parcel/transformer-inline-string": "2.0.0-rc.0",
    "parcel": "2.0.0-rc.0",

And if I try to downgrade to any other parcel version (i.e. 2.2.0), parcel will complain that @parcel/transformer-glsl needs to be 2.2.1 and will not build. All of the other plugins appear to allow consistent version numbers between the plugins and parcel itself. It is just @parcel/transformer-glsl that seems like it must be 2.2.1 regardless of parcel version.

I'm not sure what is going on, but I hope that this is a helpful clue.

I can just downgrade to 2.0.0-rc.0 in the meantime.

[mischnic]

Could you try bumping the version of @swc/helpers in your lockfile? I suspect that the swc compiler tries to call that but when you upgraded Parcel, the helpers weren't upgraded as well

[jeffpeck10x]

Aha! Yes, confirmed, force upgrading swc/helpers fixes this in the latest parcel.

This was in my yarn.lock:

"@swc/helpers@^0.2.11":
  version "0.2.12"
  resolved "https://registry.yarnpkg.com/@swc/helpers/-/helpers-0.2.12.tgz#cd54624dd685f7832b50dd7ce119ddc4eb2585ad"
  integrity sha512-hsPGC/U/0xe/WghMeSgyFsq9nNPfA5oY1Il2AaeAJcu/vTm4Bv8o9ev4eAgxcA61i5WWp72amN20XVyxWwM5aQ==

"@swc/helpers@^0.3.2":
  version "0.3.2"
  resolved "https://registry.yarnpkg.com/@swc/helpers/-/helpers-0.3.2.tgz#02b370431fb8827450577ff852d56fc5fb4e0b40"
  integrity sha512-qEru2uaH1vKZNCZR4rFCUZaflsBP7IWiGcIoQe22qi5tm+HEG/yPdhSba+ZCNTWk2xyYpx/nEFkncDY3orEx3w==

The second @swc/helpers is because parcel complains if I try to build the library package without it:

@parcel/resolver-default: External dependency "@swc/helpers" is not declared in package.json.
...
  💡 Add "@swc/helpers" as a dependency.

So, I added the latest:

    "@swc/helpers": "^0.3.2",

The first @swc/helpers@^0.2.11 however, comes from parcel's own dependencies. In the yarn.lock:

"@parcel/transformer-js@^2.2.1":
  version "2.2.1"
  ...
  dependencies:
    ...
    "@swc/helpers" "^0.2.11"

---

If I simply change my manual entry of @swc/helpers to:

    "@swc/helpers": "^0.2.14",

in the package.lock file for the library, that will consolidate @swc/helpers in yarn.lock:

"@swc/helpers@^0.2.11", "@swc/helpers@^0.2.14":
  version "0.2.14"
  resolved "https://registry.yarnpkg.com/@swc/helpers/-/helpers-0.2.14.tgz#20288c3627442339dd3d743c944f7043ee3590f0"
  integrity sha512-wpCQMhf5p5GhNg2MmGKXzUNwxe7zRiCsmqYsamez2beP7mKPCSiu+BjZcdN95yYSzO857kr0VfQewmGpS77nqA==

and the error message goes away.

This can, of course, also be fixed with resolutions or even just manually updating yarn.lock. (note to anybody reading this who is facing the same quandary.)

---

Thank you for suggesting that. A nice easy fix, and I get to stay on the latest parcel!

As for the actual bug, it seems like maybe this is the source, where this ought to point to a more recent swc/helpers:
https://github.com/parcel-bundler/parcel/blob/v2/packages/transformers/js/package.json#L38

And perhaps this line:

  💡 Add "@swc/helpers" as a dependency.

ought to direct the user to a particular version (although, in my case, I only encountered that error because I happened to building both a library and a front-end application, and the error is not applicable in the latter where this issue occurs anyway. Still, it would be helpful.)

And finally, I am not sure if this is even a bug, but it was strange when I could not downgrade from parcel 2.2.1 to parcel 2.2.0 without parcel always requiring the latest @parcel/transformer-glsl 2.2.1. Maybe this is intentional, but it seemed strange since it only affected that one parcel plugin, whereas the others had their versions in sync.

If you'd like I can make separate issues for each of these and we can close this one.

Thank you for helping regardless!

[jeffpeck10x]

fyi, I also tested this with forcing the use of @swc/helpers@0.3.2 and that worked too.

[mischnic]

So you're saying that both the old and the new version alone of @swc/helpers work fine, but when using both it doesn't work? The only difference between these cases would be Yarn not hoisting that package if there are multiple versions in your monorepo. I don't see how that could cause that error

[jeffpeck10x]

Not exactly.

"@swc/helpers@0.2.11" and "@swc/helpers@0.3.2" - does not work ❌
"@swc/helpers@0.2.14" and "@swc/helpers@0.3.2" - works 🎉
just "@swc/helpers@0.2.14" - works 🎉
just "@swc/helpers@0.3.2" - works 🎉 - forced through resolutions

The only reason that I mention the second @swc/helpers is because in my case, I was required to manually add the dependency because of this error message:

💡 Add "@swc/helpers" as a dependency.

And because it didn't tell me which version to use, I added the most recent, which was ^0.3.2, and which was treated as a separate entry from the 0.2.11 already found in the yarn.lock, which just added to confusion (because I thought "I already have the latest version!")

I think a solution would be for @parcel/transformer-js to update its dependencies to require a newer @swc/helpers, here:
https://github.com/parcel-bundler/parcel/blob/v2/packages/transformers/js/package.json#L38

But, additionally, maybe the message about adding the "@swc/helpers" could be revised to be more specific about which version to install. I am not actually clear why this even needs to be found in the dependencies anyway.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.