`ERR_LOADER_CHAIN_INCOMPLETE` issue with Node.js v18.6.0

[brianjenkins94]

Originating issue: cypress-io/cypress#22795

Search Terms

ERR_LOADER_CHAIN_INCOMPLETE, cypress

Expected Behavior

Don't short circuit on resolve? Although @cspotcode indicated that this might be a red herring.

Actual Behavior

Steps to reproduce the problem

Working on a minimal sample that doesn't include Cypress...

Minimal reproduction

Working on a minimal sample that doesn't include Cypress...

Specifications

• ts-node version: v10.9.1
• node version: v18.6.0
• TypeScript version: v4.7.4
• tsconfig.json, if you're using one:

{}

• package.json:

{}

• Operating system and version:

So far I've only seen the issue occur on Linux in CI, not Windows.

This is from the GitLab runner (Docker):

$ uname -a
Linux runner-jiyxuj1z-project-3385-concurrent-0 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ npx ts-node -vvv
ts-node v10.9.1 /project/node_modules/ts-node
node v18.6.0
compiler v4.7.4 /project/node_modules/typescript/lib/typescript.js

[cspotcode]

I'm guessing that this is being caused by a combination of the file being imported, and the file it's imported from, so I might be able to reproduce given those two bits of data, even if you don't have a complete reproduction.

[brianjenkins94]

I've actually only had the issue happen in CI so far, I just saw some buzz around the original issue and wanted to get something filed so we'd have something to work off of.

I'll see if I can identify the file being imported, and the file it's imported from.

Anybody else with something closer to a reproducible sample, feel free to chime in.

[cspotcode]

Do you think it might be related to stuff happening within node_modules? Our default "ignore" mechanism doesn't touch stuff in node_modules, so perhaps that's triggering a different code path in our hooks?

Is there at least a simple cypress invocation that reproduces it? Or perhaps is it a race condition? A lot of this loader stuff is async, maybe we're triggering a bug inside node?

[brianjenkins94]

Here is a minimal reproducible sample using Cypress: ts-node-1839.zip

Using VSCode to open the above as a dev container, reproduce with:

$ npm install
$ npx cypress run

[neuronetio]

I don't know if it matters but the latest Cypress 10.3.0 uses ts-node version 10.7.0.
AND #1714 is released in 10.8.0?
I mentioned on the Cypress repo cypress-io/cypress#22795 (comment) that #1714 is related to this bug, to let the Cypress team know that they need to update the library? (I don't know if 10.8.0 will work with the latest nodejs)

What I mean is not to do some hacks until cypress checks if the latest version of ts-node will work for them.

[brianjenkins94]

The only thing that doesn't quite add up about that is the timing. I only started seeing this issue around the 13th with the release of Node v18.6.0.

Could still be a contributing factor though. Great catch.

[cspotcode]

The absolute latest version of ts-node is required for node 18.6.0. That would be ts-node 10.9.1, which was released yesterday.

Friendly reminder for anyone reading along, that node's loader hooks are "experimental" status, with everything that implies: https://nodejs.org/dist/latest-v18.x/docs/api/esm.html#loaders

[brianjenkins94]

Okay so this is a Cypress problem, not a ts-node problem unless @faradaytrs has details relating to their issue that suggest otherwise.

[cspotcode]

That's my current guess, but if a reproduction shows this happening with ts-node 10.9.1 then I'll dig into it.

I see that the error, when it occurs, logs the path to ts-node. That should allow someone to open up the package.json and double-check the version number. Since it's always possible in node_modules trees for multiple versions of a library to be installed.

[cspotcode]

Marked "external" till we confirm with the cypress folks.