| 02:37 | <snek> | Yes, I think we should specify that, at the top level of the module, it's always a host-provided context (not necessarily empty--the host can put things there) and not based on what dynamic import triggered it (which would be racy) |
| 11:09 | <littledan> | Maybe, but it’s also possible that this proposal just won’t solve all APM problems and that we need to make tradeoffs between competing goals. Fundamentally, when you consider the merge case, preserving all of the calling contexts will take processing time, which is bad for APMs. |
| 11:12 | <littledan> | In this case, maybe specialized tooling based on transforming code could be better, as in https://github.com/nicolo-ribaudo/import-defer-polyfill |
| 11:17 | <littledan> | I don’t understand a principled way that we should decide which calling contexts to preserve. And the SES folks have made it clear that they see some cases of implicitly propagating the calling contexts to be an unacceptable information leak. But I don’t think losing the calling context in cases like this is a bad enough result to abandon the proposal entirely. |