[Bug?]: node 16.17.0 update cause yarn 3.2.2 build to fail

[shestakov-bc]

Self-service

• I'd be willing to implement a fix

Describe the bug

I apologize, I cannot provide too much information about our project, I hope other people who get here will be able to add to this. I'm reporting this, since you requested it in other issue, but sorry if this is not enough info.

Our yarn build of typescript react app is part of ubuntu image build and we are using Jenkins and CMake. We are installing node from https://deb.nodesource.com/setup_16.x which yesterday got updated from 16.16.x to 16.17.0.
Our project was using 3.2.1. After we found someone reported same issue on node 18, we found a suggestion to try

yarn set version stable && yarn install

However build is still failing on yarn 3.2.2 using node 16.17.0 with the following error logs:

[2022-08-17T04:53:35.170Z] ERRO[0690] node:internal/errors:477                     
[2022-08-17T04:53:35.170Z] ERRO[0690]     ErrorCaptureStackTrace(err);             
[2022-08-17T04:53:35.170Z] ERRO[0690]     ^                                        
[2022-08-17T04:53:35.170Z] ERRO[0690]                                              
[2022-08-17T04:53:35.170Z] ERRO[0690] Error [ERR_LOADER_CHAIN_INCOMPLETE]: "file:///blablabla/src_files/.pnp.loader.mjs 'resolve'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook's return. 
[2022-08-17T04:53:35.170Z] ERRO[0690]     at new NodeError (node:internal/errors:387:5) 
[2022-08-17T04:53:35.170Z] ERRO[0690]     at ESMLoader.resolve (node:internal/modules/esm/loader:852:13) 
[2022-08-17T04:53:35.170Z] ERRO[0690]     at async ESMLoader.getModuleJob (node:internal/modules/esm/loader:431:7) 
[2022-08-17T04:53:35.170Z] ERRO[0690]     at async Promise.all (index 0)           
[2022-08-17T04:53:35.170Z] ERRO[0690]     at async ESMLoader.import (node:internal/modules/esm/loader:533:24) 
[2022-08-17T04:53:35.170Z] ERRO[0690]     at async loadESM (node:internal/process/esm_loader:91:5) 
[2022-08-17T04:53:35.170Z] ERRO[0690]     at async handleMainPromise (node:internal/modules/run_main:65:12) { 
[2022-08-17T04:53:35.170Z] ERRO[0690]   code: 'ERR_LOADER_CHAIN_INCOMPLETE'        
[2022-08-17T04:53:35.170Z] ERRO[0690] }                       

Our only solution for now is to downgrade node to use 16.16.x during the build. Would be nice to have this resolved so we could go back to using latest stable node.

In other thread you have mentioned that it should be fixed. I wonder if there's something else need to be done, since we upgraded from 3.2.1 instead of having project on 3.2.2 from the start?

To reproduce

I'm sorry that I cannot provide more info about our project, other than this brief description:

1. setup typescript react app using yarn 3.2.1
2. use official stable node https://deb.nodesource.com/setup_16.x
3. Fail to build
4. yarn set version stable && yarn install
5. retry and still fail to build

Environment

I cannot run script to get env info, since it's a automated build environment and I'm not part of the team who set it up.
Node: 16.17.0
Yarn: 3.2.2

Additional context

No response

[Wedvich]

This is probably due to this change in 16.17: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#experimental-esm-loader-hooks-api

... (a custom loader must now signal a short circuit when intentionally not calling the next) ...

It looks like it's fixed in Yarn 4's ESM loader though - maybe that can be backported to v3 as well?

[arcanis]

This got fixed in 3.2.2. Are you sure you are using this version? Did you run yarn install after the upgrade?

[brantphoto]

This got fixed in 3.2.2. Are you sure you are using this version? Did you run yarn install after the upgrade?

@arcanis I get the same error as @shestakov-bc (yarn 3.2.2). Works on 16.16.0, fails on 16.17.0

[arcanis]

I can't reproduce:

❯ yarn --version

3.2.1

❯ yarn node --input-type module -e 'import "supports-color"'

node:internal/errors:477
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_LOADER_CHAIN_INCOMPLETE]: "file:///tmp/tmp.ik1Q7I9uPQ/.pnp.loader.mjs 'resolve'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook's return.
    at new NodeError (node:internal/errors:387:5)
    at ESMLoader.resolve (node:internal/modules/esm/loader:852:13)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async ESMLoader.getModuleJob (node:internal/modules/esm/loader:431:7)
    at async ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:78:21)
    at async Promise.all (index 0)
    at async link (node:internal/modules/esm/module_job:83:9) {
  code: 'ERR_LOADER_CHAIN_INCOMPLETE'
}

❯ yarn set version 3.2.2

➤ YN0000: Retrieving https://repo.yarnpkg.com/3.2.2/packages/yarnpkg-cli/bin/yarn.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-3.2.2.cjs
➤ YN0000: Done in 0s 416ms

❯ yarn

➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0000: └ Completed
➤ YN0000: Done with warnings in 0s 56ms

❯ yarn --version

3.2.2

❯ yarn node --input-type module -e 'import "supports-color"'


❯

[merceyz]

I cannot run script to get env info, since it's a automated build environment and I'm not part of the team who set it up.

I'm would guess the "automated build environment" has some sort of caching that isn't behaving correctly, does it work on your local machine?

[Wedvich]

I got the same error on Node >= 16.17 even on Yarn 3.2.2:

  System:
    OS: Linux 5.10 Ubuntu 20.04.4 LTS (Focal Fossa)
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
  Binaries:
    Node: 16.17.0 - /tmp/xfs-b98f7329/node
    Yarn: 3.2.2 - /tmp/xfs-b98f7329/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm

However, I started out with Yarn 3.2.0 and that's the version that generated the .pnp.loader.mjs file that's checked in to source control. Just running yarn after setting the version to 3.2.2 did nothing, but after deleting that file and running yarn again, it got regenerated with the updates and now it works 🎉

[shestakov-bc]

thanks @Wedvich maybe deleting .pnp.loader.mjs is the step we were missing. I'll try to test it tomorrow.

[Rikaelus]

I can't contribute much to this -- Node/Yarn is part of our stack but not my area of expertise -- but I can say this only recently began to affect us, too. It first showed up in our Github bors testing pipeline and is also happening on my local Windows/WSL2/Ubuntu 20.04 environment. It's even happening on weeks-old commits that tested fine at the time so it's got to be something discreetly introduced outside our stack.

Sorry I can't add anything substantive but I'm eagerly watching the thread.

[matthias-pichler]

Had the same issue, upgrading to yarn 3.2.2 and running yarn to regenerate .pnp.loader.mjs worked 👍

[shestakov-bc]

Turns out we don't even commit .pnp.loader.mjs so the problem is not with that.
I was able to build it locally successfully with node 16.17.0 + yarn 3.2.2 combo, but in our automated build (which doesn't have anything cached btw, it downloads and builds everything from scratch) it still failing with the same error.
At this point I'm going to blame our build setup, we'll have to figure it out internally.

I think Yarn 3.2.2 is fine and this issue can be closed. If/when we figure out our issue, I'll post it here for anyone who will encounter same problem.

[Rikaelus]

Just to finish off my post, we had the problem similarly go away once we got Yarn upgraded to 3.2.2. That said, while we found a solution, I'm still unnerved not knowing the cause of the problem. The problem retroactively affected weeks-old commits that, at the time of their commits, tested and functioned perfectly fine. Whatever happened seems to reveal a potential crack in the idea that once a release tests successful we can trust it to be good indefinitely.

[merceyz]

I'm still unnerved not knowing the cause of the problem

@Rikaelus You updated Node.js, most likely to 16.17.0, which changed how the experimental loaders behave.

[brantphoto]

I'm still seeing this even when deleting .pnp.loader.mjs , with updating to yarn 3.2.2... I will try and add more troubleshooting details but seems like issue persists.

[localjo]

I'm running into this problem with one of my repos. It appears that the problem might be related to experimental changes to the ESM Loader Hooks API in Node 16.17.0 in this PR. Pinning my Node version to 16.16.0 solves the problem for now. I don't have the time to dig deeper, but at first glance, it appears this is a breaking change to Node, since it breaks existing loaders that have not yet updated to signal a short circuit when not calling the next loader.

[wmertens]

The problem retroactively affected weeks-old commits that, at the time of their commits, tested and functioned perfectly fine.

If you want those sorts of guarantees you must keep your entire stack under control. I recommend using Nix for that.

[YoLoADR]

It's a node version issue. I'm using now nvm with a node@16.15.1 an it works well now

[inkyu0103]

It's a node version issue. I'm using now nvm with a node@16.15.1 an it works well now

It works to me! thx :)