Module not found: Can't resolve '#async_hooks'. Getting error with modules using sub-path imports

[alaindeurveilher]

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/sharp-spence-fyy83f

To Reproduce

The codesandbox provided displays the error message when running the application.

./node_modules/p-limit/index.js (2:0)
Module not found: Can't resolve '#async_hooks'
Did you mean './#async_hooks'?
Requests that should resolve in the current directory need to start with './'.
Requests that start with a name are treated as module requests and resolve within module directories (node_modules, /workspace).
If changing the source code is not an option there is also a resolve options called 'preferRelative' which tries to resolve these kind of requests in the current directory too.
https://nextjs.org/docs/messages/module-not-found
Import trace for requested module:
./app/page.tsx

Explanation:

In one of my projects I am using p-limit. The last update of this dependency, version 5.0.0 takes advantage of sub-path imports, which apparently NextJS 14 does not handle very well, and reports the error above when compiling the page.

Current vs. Expected behavior

Expected behaviour:

No error should be raised with the module p-limit used in a server component.

Verify canary release

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

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
Binaries:
  Node: 20.8.1
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.0.1
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A

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

Not sure

Additional context

I did not actually try with canary on codesandbox because when canary, the appDir was said to be experimental. So the example given is with version 14.0.1 of NextJS.

[GabenGar]

What are the values of "module" and "moduleResolution" in your tsconfig.json?
Subpath imports is a nodejs/bundler thing, so what exactly is a context you expect p-limit, a nodejs package, to be called at?
p-limit specifically depends on async_hooks module of nodejs, so cannot be used outside of it, aka no browser.

[alaindeurveilher]

Hello,

In my tsconfig.json file I have the following default configuration:

    "module": "esnext",
    "moduleResolution": "node",

I am using p-limit at the moment in the (server) action of a form to handle multiple promises in parallel. So it is performing on the server side.

[GabenGar]

Does changing "moduleResolution" to "bundler" fix the problem?

[alaindeurveilher]

I tried, but changing moduleResolution to bundler did not fix the problem.

[GabenGar]

The crutch is p-limit uses subpath imports in its package.json, to conditionally load async_hooks with a stub outside of node environments. Possibly the nextjs bundler (turbopack and/or webpack) is being confused there, because, as far as package structure concerned, it should "work" as in not crash at module resolution time.

[Jeromearsene]

I have the same error with App Router structure.
I've p-limit in my route.ts:

Any update ?

I've check closed issue on p-limit repo: sindresorhus/p-limit#72

The problem is solved if i use p-limit@4.0.0. Only crash on version 5.

[mokkabonna]

For reference I solved this from failing in jest by having the following jest config: (this is inside my package.json)

 "jest": {
    "moduleNameMapper": {
         "^#async_hooks": "<rootDir>/node_modules/p-limit/async-hooks-stub.js"
    },
    "transformIgnorePatterns": [
      "<rootDir>/node_modules/(?!yocto-queue|p-limit)"
    ]
  },

[jpshack-at-palomar]

Just noting that this is still an issue. sindresorhus/p-limit#72

[colinfindlay-nz]

The error generated is caused by specific (incorrect) behaviour in webpack/enhanced-resolve
This has been addressed in v5.17.1 - but afaik Next still relies on v5.16.0

https://github.com/webpack/enhanced-resolve/releases/tag/v5.17.1

This is also affecting our builds for internal packages