Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
esm: provide named exports for builtin libs #20403
provide named exports for all builtin libraries so that the libraries may be
continuation of #18131 because it got too long and github was giving unicorns
@guybedford i'm not quite sure what the setter-based approach looks like (do we iterate through the exports and re-assign every property to have get/set instead of value?) how do we prevent common ways that userland monkeypatches while keeping property values updated (defineProperty) how do we make sure that deleted properties become representative in esm land
@guybedford it is worth noting that the added time is from the iterating and creation and such at startup, not from actually calling those traps. i'm can't think of how you will build hundreds of getter/setters in less time while still having the majority of the same code for enumerable filtering and such
@guybedford The perf run mentioned was done on an incomplete implementation. None of the methods in your hot code example are wrapped (
Perf is important (duh), and at this stage it's good to keep an eye on for sure. There's plenty of perf work to be done on ES modules in Node in general (and that work will come). Since this is experimental things should be allowed to progress and take shape. Any performance concerns you have about specific JS constructions should be filed for V8 to tackle (there's plenty of runway to improve whatever needs improving).
You too could experiment with your own implementation without obstructing. If a better implementation shakes out down the road then so be it.
I've done an initial review here - looking through this more closely it is looking really great actually!
Agreed a setter approach would incur a lot of property definitions that might slow us down more anyway.
@jdalton points taken that we can improve perf here over time. I ran some initial subsets of the benchmarks against this code and haven't yet spotted any issues, but it's worth keeping an eye on the hot paths here.
@devsnek I would really appreciate it if you can help me understand the wrap magic to more properly review. I'll also aim to stare at it again this week if I get a moment. I must admit the layered proxy situation also doesn't seem ideal from a perf perspective, so would be nice to be able to follow the driving use cases to see where hot paths might be carved out from that further.