nx: Unit test fails with an upgrade (NX Running target "test" failed)
Initially errored as follows,
● Test suite failed to run
The service is no longer running
at ../../../../node_modules/esbuild-wasm/lib/main.js:1276:29
at sendRequest (../../../../node_modules/esbuild-wasm/lib/main.js:625:14)
at start (../../../../node_modules/esbuild-wasm/lib/main.js:1274:9)
at ../../../../node_modules/esbuild-wasm/lib/main.js:1742:82
and then got below error with a bunch of tests failed,
NX Running target "test" failed
Tasks not run because their dependencies failed or --nx-bail=true
The failed jobs never attempted to run and simply fails. it’s happening only on the GitLab pipelines!.
is there anything changed on the affected:test that can cause this failure?
Can someone please advise on this?
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 4
- Comments: 22 (11 by maintainers)
I am affected by this too… tests all running locally but in Gitlab CI environment some run and some fail with an error similar to the original post:
Since update from Nx 13 to 14.
So did some more debugging today, this looks to be related to esbuild process getting killed via host system due to resource limits.
I did some investigation via nrwl/nx-examples/pull/209 and was able to get the error of esbuild trying to write to a close pipe
as for the fix here, I’m not 100% sure nx can do much. Some things to try is to lower the # of parallel threads running via
--parallelflag and using the-runInBandflag when running in CI, Other wise Jest will spin up worker threads that include running the esbuild transformer. You can also try bumping the memory on your CI agents.Now as to why the native esbuild binary isn’t able to run I’m not sure. There could be various reasons why esbuild native isn’t able to run like anti-virus incorrectly flagging it
jest-preset-angular falls back to esbuild-wasm if it cannot load esbuild, like angular. so that’s why it’s present, to begin with.
I would be interested if y’all could try some of the suggestions of lower the parallelism of nx and jest tests and seeing if the tests go away also checking if increasing the CI providers memory helps in any way.
only real change to jest has been how the default preset has to be imported. which is by default in your root jest.preset.js file, but you could be using it in other places. the v14.1.5 migration should have taken care of this for you. also, the output from running
nx reportwould be a helpful place to start for debugging.for those coming across this issue, the (sort of) root cause was from a jest-preset-angular version missmatch. so when trying to check for esbuild it was throwing an error causing it to always fallback to esbuild-wasm. with the jest 28 support (#10857) the correct versions are synced back and should go away once migrating.
@barbados-clemens running with
--parallel=1worked for me, thanks!@dean-g goal is to get the PR merged for Jest 28 this week, I have a few things with cypress 10 to finish first.