-
Notifications
You must be signed in to change notification settings - Fork 551
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
ESM tests are failing with Node v18.19.0 #1872
Comments
This is as a workaround for ESM testing failing with v18.19.0 due to node's off-thread ESM loading and import-in-the-middle's limitation with reexports. Refs: open-telemetry#1872
This is as a workaround for ESM testing failing with v18.19.0 due to node's off-thread ESM loading and import-in-the-middle's limitation with reexports. Refs: #1872
) This is as a workaround for ESM testing failing with v18.19.0 due to node's off-thread ESM loading and import-in-the-middle's limitation with reexports. Refs: open-telemetry#1872
Looks like nodejs/import-in-the-middle#30 has merged, we should be able to unpin when the next ittm release is out 🙂 |
For documentation purposes: We've tried unpinning but ran into nodejs/import-in-the-middle#57 which means our ESM checks don't work. |
Many ESM tests using the import-in-the-middle (IITM) hook (i.e.:
node --experimental-loader=@opentelemetry/instrumentation/hook.mjs ...
) fail when tested with Node v18.19.0 (and Node v20.x) with an error similar to:The issue is as follows. In Node.js v20, Node.js's internal ESM loader changed to do its loading off of the main thread. This change required the import-in-the-middle library to use a different mechanism for determining the set of exports from a CommonJS module being imported. That mechanism has a limitation that it does not support re-exports (exports resulting from
export * from './somefile';
). nodejs/import-in-the-middle#29The limitation was not initially an immediate issue for CI in this repo, because currently Node.js v20 is not being tested in CI. Then Node.js backported this ESM off-thread loading to Node.js v18.19.0.
The correct fix is an updated IITM with a fix for that issue. There is a PR (nodejs/import-in-the-middle#30) that hopefully will be considered soon.
temporary workaround
As a temporary workaround, we could:
v18.18.2
(the latest release before v18.19.0).>=18.19.0
, and optionally consider testing18.18.2
and18
.Given that we hope the import-in-the-middle limitation to be resolved fairly soon in the new year, I favour option 1 for now.
The text was updated successfully, but these errors were encountered: