turbo: [WEB-964] [Turbopack] Error resolving commonjs request
What version of Turbopack are you using?
included in next@13.0.0
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Mac
Describe the Bug
I get the following stack trace when I start my next application with next dev --turbo --show-all and I try to load a page.
The page doesn’t load.
thread 'tokio-runtime-worker' panicked at 'not yet implemented: emit an error for this case: apply need to be used', /Users/runner/.cargo/git/checkouts/turbo-df7a549334890fa5/5603994/crates/turbopack-ecmascript/src/references/pattern_mapping.rs:85:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at 'not yet implemented: emit an error for this case: apply need to be used', /Users/runner/.cargo/git/checkouts/turbo-df7a549334890fa5/5603994/crates/turbopack-ecmascript/src/references/pattern_mapping.rs:85:17
thread 'tokio-runtime-worker' panicked at 'not yet implemented: emit an error for this case: apply need to be used', /Users/runner/.cargo/git/checkouts/turbo-df7a549334890fa5/5603994/crates/turbopack-ecmascript/src/references/pattern_mapping.rs:85:17
thread 'tokio-runtime-worker' panicked at 'not yet implemented: emit an error for this case: apply need to be used', /Users/runner/.cargo/git/checkouts/turbo-df7a549334890fa5/5603994/crates/turbopack-ecmascript/src/references/pattern_mapping.rs:85:17
thread 'tokio-runtime-worker' panicked at 'not yet implemented: emit an error for this case: apply need to be used', /Users/runner/.cargo/git/checkouts/turbo-df7a549334890fa5/5603994/crates/turbopack-ecmascript/src/references/pattern_mapping.rs:85:17
thread 'tokio-runtime-worker' panicked at 'not yet implemented: emit an error for this case: apply need to be used', /Users/runner/.cargo/git/checkouts/turbo-df7a549334890fa5/5603994/crates/turbopack-ecmascript/src/references/pattern_mapping.rs:85:17
thread 'tokio-runtime-worker' panicked at 'not yet implemented: emit an error for this case: apply need to be used', /Users/runner/.cargo/git/checkouts/turbo-df7a549334890fa5/5603994/crates/turbopack-ecmascript/src/references/pattern_mapping.rs:85:17
thread 'tokio-runtime-worker' panicked at 'not yet implemented: emit an error for this case: apply need to be used', /Users/runner/.cargo/git/checkouts/turbo-df7a549334890fa5/5603994/crates/turbopack-ecmascript/src/references/pattern_mapping.rs:85:17
error -
[resolve]
/Users/leonard/code/capsule/node_modules/.pnpm/@sentry+cli@1.74.5/node_modules/@sentry/cli/js/helper.js
Error resolving commonjs request
unable to resolve dynamic
/Users/leonard/code/capsule/node_modules/.pnpm/@sentry+cli@2.7.0/node_modules/@sentry/cli/js/helper.js
Error resolving commonjs request
unable to resolve dynamic
/Users/leonard/code/capsule/node_modules/.pnpm/jsdom@20.0.0/node_modules/jsdom/lib/jsdom/living/xhr
Error resolving server relative import: not implemented yet
unable to resolve server relative "/ROOT/node_modules/.pnpm/jsdom@20.0.0/node_modules/jsdom/lib/jsdom/living/xhr/xhr-sync-worker.js"
/Users/leonard/code/capsule/node_modules/.pnpm/jsdom@20.0.0/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js
Error resolving commonjs request
unable to resolve server relative "/ROOT/node_modules/.pnpm/jsdom@20.0.0/node_modules/jsdom/lib/jsdom/living/xhr/xhr-sync-worker.js" or module "null"
/Users/leonard/code/capsule/node_modules/.pnpm/jsdom@20.0.0/node_modules/jsdom/lib/jsdom/utils.js
Error resolving commonjs request
unable to resolve module "canvas"
/Users/leonard/code/capsule/node_modules/.pnpm/node-fetch@2.6.7/node_modules/node-fetch/lib/index.mjs
Error resolving commonjs request
unable to resolve module "encoding"
/Users/leonard/code/capsule/node_modules/.pnpm/ws@8.8.1/node_modules/ws/lib/buffer-util.js
Error resolving commonjs request
unable to resolve module "bufferutil"
/Users/leonard/code/capsule/node_modules/.pnpm/ws@8.8.1/node_modules/ws/lib/validation.js
Error resolving commonjs request
unable to resolve module "utf-8-validate"
Expected Behavior
I would expect to be able to load a page as like when I use next dev.
To Reproduce
Not sure how to reproduce but it might be relevant to add some context:
- I use turbo 1.6.1
- I use pnpm workspace
Reproduction Repo
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 58
- Comments: 31 (6 by maintainers)
Any news on this? Removing
tsconfig.jsondoes not seem like an optimal fix.Had the same issue, removing my
tsconfig.jsonfile seemed to resolve the issue.In the new learn of nextjs, if you dev start command with --turbo, calling await fetchRevenue in the example will report the same error. https://nextjs.org/learn/dashboard-app/fetching-data
nextjs version 14
yarn dev --turbo is also failing for me on next 14
Came here looking to see if anyone else had the same issue. Also get these using
next dev turbo --show-allafter trying upgrading a next 12 project to 13. Withnext devand noturbo, everything ok.Hey all, we’ve been making a lot of progress on these types of issues over the last 3 weeks. I just ran the /learn application and it now compiles correctly whereas it errored on 14.0.3. Please give
npm install next@canarytry. Based on the comments in this issue everyone was running into different issues. If you’re still running into issues please open a new issue with a reproduction so that we can investigate and fix the particular case that you’re running into.Thanks!
Next.js has greatly enhanced the full-stack development experience for many. It’s hard to dispute Vercel’s success in this regard.
However, I do wish Next.js had opted for a more established development runner and compiler, such as Vite with ESBuild. The development experience I’ve had with Vite projects, particularly in terms of cold starts and hot reloads during development, is notably superior, 12 seconds for initial load with Turbo versus instant >50ms with Vite.
Additionally, the compilation time and resource requirements are substantially lower with Vite.
Is there any chance Next.js might consider adopting Vite in the future, or is that possibility unlikely?
After 13 monthes of reporting the issue. It still hasn’t been resolved!
Same for us
Also getting this on the latest version
13.4.13:I also have the same problem on next 14
Same here :
Nice, I’m no longer seeing this error in 14.0.4-canary.28!
Honestly Vercel has become a joke – I’ve used Next.JS since the very beginning and I’ve seen a huge downgrade in performance and community support in addressing these types of issues.
link @timneutkens from your comments there, i tried using turbopack but this issue is blocking me to run next dev --turbo. I hope and trust you guys will resolve this. but this issue stands for over an year here. this is the exact error i am now seeing.
Error resolving EcmaScript Modules request unable to resolve module "fs" It was not possible to find the requested file. Parsed request as written in source code: module "fs" Path where resolving has started: [project]/node_modules/@aws-sdk/credential-provider-web-identity/dist-es/fromTokenFile.js Type of request: EcmaScript Modules request Import map: No import map entryhey any update on this issue? I’m having the same errors
I think there are a few issues being reported here.
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).Solved in canary for me too, especially supabase and supabase ssr work now.
I have the same issue :
There’s some bad presentation for the error logs, but the core issue is:
The
childProcess.execFileand related “very dynamic” should be warnings, I’m not sure why they’re presented with the actual errors above.