-
-
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
Implement async dependency resolution #9505
Comments
Any chance of seeing this one in 27? This would unblock vitejs/vite#1955 and allow first-class integration of Jest into Vite. I am willing to help bring this to life but I would need some guidance as I'm not really familiar with jest and it's internals |
PRs are very much welcome! 👍 Similar to how we did async transform (#9889), you can start by adding support to Note that Once |
I would like to help here, but am not quite sure where to start. @SimenB Is there a reference and just a matter of implementing this to a new context? |
Is there any roadmap on implementing this? I believe it’s having quite a significant knock on effect with build tools that wish to use Jest but cannot, Vite being one example. |
@lloydjatkinson I need to rebase #11540, but it sounds like Simen is ready to give it a review once I do, and then get it into Jest 28. |
Yep, I'll make sure it's in 28 before releasing it to give a nice major target version for downstream 🙂 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Similar to #9504, but for dependency resolution. Like there, this wouldn't be used by Jest just yet, but could (and would, if support is implemented) be used by the ESM support. This logic is implemented in
jest-resolve
.I wonder if it makes sense to reintroduceresolve
as a dependency since this already has an async code path. That is callback based, but just promisifying that should work fine. But the increased complexity ofmjs
,cjs
etc makes me want to depend on a dedicated module rather than have that complexity live in Jest itself - Jest should just manipulate resolution based onmoduleNameMapper
etc and possibly cache some stuff on our side.resolve
was actually removed in #4315, via #2925. Some of #2925 reasoning was thatresolve
was somewhat unmaintained and that we didn't need the async parts of it - neither of which are true anymore.Added in #9520
import.meta.resolve
has landed on node master (nodejs/node#31032, albeit currently behind a flag), so we'll need to implement this regardless of whether we'd want to use it ourselves or notThe text was updated successfully, but these errors were encountered: