19:31 | <snek> | joyee: i was trying to understand the different approaches for injecting __esModule on require(esm) on your pr, and reading through it looked like they were all roughly the same performance? i'd like to just use a proxy if possible, but since you went with the wrapper module approach i wanted to double check it wouldn't be bad in some way i haven't seen mentioned. |
20:26 | <joyee> | The performance difference shows up when you are accessing properties from the returned result, which is relevant for bundled code because they always access it as const loaded = require('esm'); loaded.prop instead of caching const {prop} = require('esm') (in order to preserve live binding) |
20:27 | <joyee> | https://github.com/nodejs/node/pull/52166#issuecomment-2223998497 |
20:27 | <joyee> | That's the type='access' benchmarks |
20:29 | <joyee> | For module loading per-se the difference is not too big, the difference lies in property access (or, from the faux-ESM user's POV, every access to named exports from another module)
|
20:31 | <joyee> | There are some examples of the code emitted by the transpilers, who are what the __esModule thing is for https://github.com/nodejs/node/pull/52166#issuecomment-2145702846 |
20:34 | <joyee> | It would be cool if non-enumerable exports are allowed though, the wrapper module makes __esModule enumerable, which is a bit annoying |
20:43 | <snek> | That's the type='access' benchmarks |
20:43 | <snek> | yeah i was wishing while writing this that there was a host hook for initializing namespaces. but it would be kind of silly... |
20:48 | <joyee> | I think when faux-ESM becomes a past, we can just switch to Proxy, until them using the module wrapper would avoid risking making native ESM unattractive (because your faux-ESM user might see funny hot spots of all the Proxied named exports access from your module) |
20:49 | <joyee> | Or better, having non-enumerable exports, then __esModule is barely visible |