1

I have an app that uses Next.js 13. I have been running it with Turbopack and a few commits ago it stopped working. It now fails with a vague error. It says TypeError: Class extends value # in the browser, Uncaught ReferenceError: $RefreshSig$ is not defined in the browser console, Error during SSR Rendering TypeError: Class extends value #<Object> is not a constructor or null. This is what it looks like in the browser:
enter image description here

If I could just get a more specific error I could start to debug. The launch script in my package.json file looks like this for turbopack "next dev --turbo --show-all"

So how do I get a more specific traceable error?

juliomalves
  • 42,130
  • 20
  • 150
  • 146
ChristianOConnor
  • 820
  • 7
  • 29
  • 1
    do you have github repo. I haven't worked on next 13 turbo yet. I am curious about this error – Yilmaz Nov 23 '22 at 03:46
  • I've isolated the error to 1 node module that I need for a project called `list-js-sdk`. I made this repo. Please follow the readme to throw the error https://github.com/ChristianOConnor/lit-protocol-nextjs-turbopack-fix. – ChristianOConnor Nov 23 '22 at 05:51
  • 1
    I searched the issue and I think there is a circular dependency issue. somehow next.js-webpack handles this or maybe babel does not even create any circular dependency when transpiling. but next. js-turbo transpilation is causing circular dependency and cannot handle it – Yilmaz Nov 24 '22 at 06:36
  • Oh that's amazing that you isolated it! Do you know about any fixes? – ChristianOConnor Nov 25 '22 at 00:38
  • 1
    I need to know more about the turbo. that is the actual reason I asked for your repo. I was scared of those issues. webpack is supported by the community via plugins. If there was an issue, one guy creates a plugin, submits to npm and issue is solved. I do not how turbo pack will solve the issues as we go – Yilmaz Nov 25 '22 at 01:24
  • Here's turbopack's website https://turbo.build/pack, here is their github https://github.com/vercel/turbo, and here is the `lit-js-sdk` github page https://github.com/LIT-Protocol/lit-js-sdk. Is this what you need? – ChristianOConnor Nov 25 '22 at 02:02
  • 1
    I got an error which is an open issue in github: https://github.com/vercel/turbo/issues/2361 – Yilmaz Nov 25 '22 at 02:40
  • 1
    [...]/node_modules/node-fetch/lib/index.mjs Error resolving commonjs request unable to resolve module "encoding" – Yilmaz Nov 25 '22 at 02:41
  • Oh that's amazing! I wasn't able to trace the error so that's incredible that you were able to get the specific error. How did you throw it? Is it possible to share a screenshot? If not that's totally cool. – ChristianOConnor Nov 25 '22 at 02:55
  • 1
    Run `yarn add encoding` in your project directory, to be honest it resolved my issue. – Arshad Ali Feb 22 '23 at 08:50

1 Answers1

2

there are two open github issues:

https://github.com/vercel/turbo/issues/2361

[...]/node_modules/node-fetch/lib/index.mjs Error resolving commonjs request unable to resolve module "encoding"

I installed encoding inside the directory (I made some other changes but I forgot) and then I got another error:

enter image description here

It is an also has an open issue: https://github.com/vercel/turbo/issues/2372

From the last open issue, someone commented:

I think there are a few issues being reported here.

1- Node stdlib requires/imports are failing

2- Highly dynamic requires/imports are failing

I think we can get stdlib imports to work in SSR, and should stop that error from reporting. If you use it in client side, then we need to still warn.

For the dynamic requires (it's using eval!), this is challenging to support. Again, we could just let node handle it, but that'll break if you're trying to do a relative require (this case requires a node_module, which would work ok).

I think this clearly explains the issue. turpopack will give us alot of headache.

Yilmaz
  • 35,338
  • 10
  • 157
  • 202