-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat: Sync import.meta.resolve #2504
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
base: main
Are you sure you want to change the base?
Conversation
File size impactMerging feature/context-sync into main will impact 2 files in 2 groups. browser (0/2)No impact on files in browser group. node (1/1)
extras (1/9)
|
Ping @jolyndenning for review on this one as co-maintainer. |
* ensure that original properties are preserved * replace spread operator with Object.assign for better downstream support
d7c14a9
to
e7b7732
Compare
updated comment block
5e4c7f1
to
6570b11
Compare
I'd prefer changing the default implementation rather than adding an extra for this. Doing so would be a breaking change to SystemJS, but would match browser and nodejs behavior. See related #2504 where changing to sync was discussed. Also see https://nodejs.org/api/esm.html#importmetaresolvespecifier and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta/resolve, which both now say that resolve returns a string rather than a promise. |
@@ -1,3 +1,6 @@ | |||
SystemJS 6.12.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changelog in this project has usually been created by the person releasing the code
I'd be happy to update the core implementation, if there is an appetite for a major version release. @jolyndenning @guybedford is there a 7.x timeline? |
I don't know if systemjs will ever have another release. Migrating to native modules is preferred. |
@jolyndenning I assumed that there was some openness to a new release since you were flagged for review. @guybedford there seems to be some impasse on if a major version (or even a minor version) is in the cards? Approaching this as an Extra would make this optional for adoption, or the alternative PR implements the breaking change. I do think the type inconsistency makes this potentially mostly source compatible with older Node code? If somebody found that context.resolve returns a promise and adds an await such that they can resolve the value - then the new runtime behavior for that code would continue to be correct, since awaiting a primitive results in the same value. I think the only odd thing is if somebody asserted on the type of the return value. |
Actually no it wouldn't be source compatible since it would no longer be then-able |
Suggests that import.meta.resolve should support synchronous usage.
see: #2503