-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ESM] Jest crashes with request for ... is not yet fulfilled
linking error
#11434
Comments
I know nothing about this other than what the GH search surfaced, but:
|
Interesting find! The error is thrown when I've tried for about an hour to understand why it goes boom without luck... Might need to ask in the node repo. I think we currently do only call Do you think you would be able to create a reproduction outside of the babel repo? I tried to add a failing test to this repo without success. test('import same file in parallel indirectly', async () => {
await Promise.all([import('../file1.js'), import('../file2.js')]);
}); and then both import func from './sharedImport.js';
func(); and export default function func() {
console.log('woop');
} This passes instead of failing with the same error, though. |
Sure, I can try 👍 |
https://github.com/nicolo-ribaudo/jest-bug-not-yet-fulfilled
|
Node throws if the promise isn't already resolved: https://github.com/nodejs/node/blob/e46c680bf2b211bbd52cf959ca17ee98c7f657f5/src/module_wrap.cc#L534 However, it seems in contrast with the idea behind promises: the "settled" status shouldn't be observed, a promise already resolved to |
same issue here, but I can't tell the detail. It's to complicated lol It's only happen when I test my app with jest. In production is fine this is the copy of my code const runServices = async (routes, routeMiddleware) => {
await Promise.all(["post", "get", "patch", "put", "delete"].map(async (method) => {
await Promise.all((routes[method] || []).map(async (r) => {
let service;
let localMiddleware = [];
try {
const instance = await import(servicePath + r.service);
service = instance.default || instance;
(service.middleware || []).forEach((m, i) => {
let mInstance = m.default || m; //multer imported here
localMiddleware[i] = async (req, res, next) => {
try {
await mInstance(req, res, next);
}
catch (err) {
handleError(req, res, err);
}
};
});
router[method](routes.prefix + r.path, ...routeMiddleware, ...localMiddleware, async (req, res) => {
try {
await serviceExec(req, res, service);
}
catch (err) {
handleError(req, res, err);
}
});
}
catch (err) {
Log.fatal(err);
}
}));
}));
}; System: |
Hi I have same issue with oas-tools getting 'request for ./middleware/index.js is not yet fulfilled' oas-tools/oas-tools#342 |
Same here. Having problems when using @oas-tools/core. |
Again, this is a node (or rather, v8) bug linked above. Until that's fixed, no need to add any "+1"s to this issue |
Is it possible to know when this issue is schedule to be resolved? or maybe a workaround? |
You can track any of the issues linked in nodejs/node#37648 |
I'm still hitting this issue. This has not yet been resolved? In my situation I have code like the following:
It's failing in either the if or the else on the import. That dynamic import opens up a module who's first line is the following:
And the error I'm getting is:
|
When using jest this code gets transpiled to `require` and the file URL syntax of the import is not supported and breaks the testing environment. This change only uses file URL import syntax on windows machines. This fixes our tests and is still supported on linux and mac operating systems. I think windows is definitely in the minority here and we should not optimize for it. Furthermore, I believe using a UNC path would be a better solution outright but I cannot test because I don't have a window machine at hand. Why not just use jest's `--experimental-vm-modules` flag? Glad you asked. Because of this [jest bug](jestjs/jest#11434 (comment)) which is caused by this [node bug](nodejs/node#37648) which is ultimately caused by this [v8 bug](https://issues.chromium.org/issues/40784051)
🐛 Bug Report
When two modules dynamically imported in parallel depend on the same file*, Jest crashes with a
request for ... is not yet fulfilled
error. The error is thrown by https://github.com/nodejs/node/blob/e46c680bf2b211bbd52cf959ca17ee98c7f657f5/src/module_wrap.cc#L535, so it's possible that this is a Node.js bug and not a Jest bug.In my repository example below, I import two files in parallel (if I import them serially the test passes):
https://github.com/nicolo-ribaudo/babel/blob/31dac517b7ce0d504bda794075f0a88029cedd58/packages/babel-plugin-proposal-private-methods/test/repro.js#L6-L7
Those two files both depend on
packages/babel-helper-create-class-features-plugin/lib/index.js
.packages/babel-helper-create-class-features-plugin/lib/index.js
depends onpackages/babel-helper-create-class-features-plugin/lib/fields.js
, and the error I get is about that file:To Reproduce
Repository link: https://github.com/nicolo-ribaudo/babel/tree/jest-esm-request-not-yet-fulfilled-error
Steps to reproduce:
Expected behavior
It shouldn't crash
envinfo
It also fails with Node.js 16.2.0
The text was updated successfully, but these errors were encountered: