-
-
Notifications
You must be signed in to change notification settings - Fork 9.1k
[experiment] implement tc39 Defer Module Evaluation #16567
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
Yeah, we can implement this under the |
For maintainers only:
|
7420ab0
to
32408f7
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Just update snaphots (
|
Is it locally? |
This comment was marked as resolved.
This comment was marked as resolved.
@Jack-Works Sounds like a bug in jest... do you use the same steps as in our CI file? Based on CI report you just need to update snapshot, no more |
Can you update |
This comment was marked as resolved.
This comment was marked as resolved.
@Jack-Works What is node version? You can try to change, also just check you have the same versions as in the lock file |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Weird, I don't have problem with jest locally... Okay, we can try to update jest (maybe new versions resolve this problem) Also can you use |
This comment was marked as resolved.
This comment was marked as resolved.
I tried to add some test cases (6041d87) but it seems like does not work... Did I do right? |
You can use virtual machine here 😄 |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
9161b0f
to
5250fd6
Compare
CodSpeed Performance ReportMerging #16567 will degrade performances by 82.72%Comparing Summary
Benchmarks breakdown
|
CodSpeed Performance ReportMerging #16567 will degrade performances by 23.26%Comparing Summary
Benchmarks breakdown
|
The same test becomes 23% slower in development and 23% faster in production? 🤔 |
hi @alexander-akait I think it is ready now! |
@@ -46,6 +46,8 @@ class ImportParserPlugin { | |||
Array.from(enumerable, e => [e]); | |||
parser.hooks.importCall.tap("ImportParserPlugin", expr => { | |||
const param = parser.evaluateExpression(expr.source); | |||
// TODO support deferImport | |||
// this requires the evaluateExpression to support Object literals. |
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.
@Jack-Works So we don't support import('something', { defer: true })
? Do we have this in spec?
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.
@Jack-Works So we don't support
import('something', { defer: true })
? Do we have this in spec?
No, the syntax becomes import.defer('something')
(this comment is written in a very early stage), I'll update this soon.
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.
Thank you
* @this {TODO} | ||
* @param {TODO} node node | ||
* @returns {TODO} import.meta | ||
*/ |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
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.
@Jack-Works Sorry for delay, there are two question, and we can merge (want to merge it this week), thank you for your work
Co-authored-by: Nicolo Ribaudo <hello@nicr.dev>
updated, but |
@Jack-Works Just for information - any blockers for |
Not yet, I didn't do any research on this because I'm focusing on other things right now. I emit this error to make the PR merge-ready (without a breaking |
Fyi, TypeScript just merged support for this :) |
])},`, | ||
`defineProperty: ${runtimeTemplate.basicFunction("_, name", [ | ||
init, | ||
// TODO: |
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.
What we should do here in future?
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.
A Module Namespace object's defineProperty checks the new property descriptor. It only returns true
when the new property descriptor is the same as the current one.
This behaviour is skipped since webpack's implementation (lib/runtime/MakeNamespaceObjectRuntimeModule.js
) for normal namespace object is skipping this too.
environment: { | ||
optionalChaining: false | ||
} | ||
}, |
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.
Very weird, I will resolve it before merge, no need action from you
Does this PR introduce a breaking change?
no?
What needs to be documented once your changes are merged?
Defer import
This implements the semantics of the TC39 proposal Deferring Module Evaluation.
New options:
experiments.deferImport: true
To use the native syntax, install
acorn-import-defer
as a peer dependency.Result:
Other things to notice
Alternative syntax
can be written as
I suggest putting the magic comment after the
from
keyword, which is compatible with TypeScript, Babel, SWC, and Flow if the necessary option to preserve comments is enabled.Please do not put it after the "import" keyword (like
import /* webpackDefer: true */ * as ns from './mod.mjs'
), the filesystem cache is broken, and I don't know why.ESBuild is not compatible, please read evanw/esbuild#1439 and evanw/esbuild#309. Esbuild may support this feature ad-hoc like other webpack magic comments.