[wip] feat(@jest/environment, jest-resolve, jest-runtime): support URL as module specifier in mocking APIs #14332
Conversation
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Yeah, this would be awesome! 👍 |
|
Thanks for encouragement. I just think my current approach is wrong: ignoring schemes is not the same as to support them. Would be better to use URL strings as module identifiers instead of current module ID logic. That is more or less what Node does in with EMS modules. Worth to give a try. Also it would be too much to have support Node v14. So this can land only with Jest 30. I can think slowly. |
|
Using strings as identifiers under the hood sounds like a good idea 👍 |
|
This one is rather involving. Can find spare time at the moment. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Fixes #14040
Closes #14297
Summary
The idea is to support URL strings and URL objects as module specifiers in mocking APIs. Recent versions of Node allow URLs almost everywhere where module specifier can be passed. So this feels like a natural step forward. For the beginning I think it is better to focus on mocking APIs only, altho there are other APIs in Jest packages which could take URL.
This PR is based on the ideas I came up while reviewing #14297. I think the problem is not the
node:schema, but the fact thatjest-resolvewas not made to support URL. That is relatively new feature in Node.For example, currently Jest logic treats
node:fsandfsas two separate modules. Adding support for URL specifiers this gets solved. That is not just about strippingnode:, but about supporting URL strings.This also can be useful for ESM where
import.meta.urlis an URL string. I don’t have any use case, but in theory dynamic mocking and importing based onimport.meta.urlcould be implemented.Test plan