| 16:00 | <nicolo-ribaudo> | I'm a couple minutes late |
| 17:00 | <jakobjingleheimer> | guybedford nicolo-ribaudo i took a quick look, and i might actually be able to facilitate import.meta.load(). I'm doing a quick PoC right now. |
| 17:03 | <nicolo-ribaudo> | I assume that is as much problematic to Guy as .require :P |
| 17:06 | <jakobjingleheimer> | Why? Isn't his objection about commonjs? (import.meta.load() would use esm) |
| 17:06 | <jakobjingleheimer> | Recording and summary of today's meeting: https://app.fireflies.ai/view/TC39-Module-Harmony::qn4hiX7NVrtLJ7ax |
| 17:08 | <nicolo-ribaudo> | Why? Isn't his objection about commonjs? (import.meta.load() would use esm) |
| 17:14 | <guybedford> | I think statically analyzable import capabilities belong in TC39 |
| 17:14 | <guybedford> | and import.meta is a dangerous place for things in general |
| 17:14 | <guybedford> | that we should have a very high bar for |
| 17:15 | <guybedford> | but Node.js can have module loading helpers under its builtin modules that offer features like preloading etc for sure |
| 17:15 | <guybedford> | just like browsers have custom preloading |
| 17:15 | <guybedford> | I'd just suggest it be a import { preload } from 'node:module' or something like that so it's clear it's Node.js specific |
| 17:23 | <jakobjingleheimer> | Isn't import.meta that space? Also, that's where node-like runtimes are supposed to put these sorts of things. There are cumbersome drawbacks to it being on node:module instead of import.meta. Notably: This is possible: This is not: Instead it would have to be Or preload('./foo.js', import.meta.url) |
| 17:24 | <jakobjingleheimer> | Btw my initial PoC for import.meta.load is working. I'd need to try it with a loader registered to say it's likely possible. But if it doesn't facilitate what you want, then i won't bother |
| 17:26 | <jakobjingleheimer> | It facilitates what i want though 😜 |
| 19:12 | <jakobjingleheimer> | guybedford 👀 |
| 19:37 | <guybedford> | import.meta is dangerous in the context of things not being standard, while import x from 'node:x' is clearly Node.js specific |
| 19:38 | <guybedford> | there was discussion in the past about import.meta.node.feat as being environment-specific |
| 19:38 | <guybedford> | even that still concerns me though... |
| 19:43 | <jakobjingleheimer> | That's what WinterCG is for and possibly TC-something when WinterCG gets promoted |
| 19:46 | <guybedford> | yeah that would be ideal for import.meta stuff, with a high bar for criteria of what is required for its standards |
| 19:55 | <jakobjingleheimer> | Soooo sounds like Guy's onboard |
| 19:58 | <kriskowal> | What does this preload facility do? |
| 19:58 | <kriskowal> | Is it effectively a transitive import source? |
| 20:01 | <jakobjingleheimer> | What does this preload facility do? |
| 20:03 | <kriskowal> | Yeah, so in terms of module harmony, that’d drive the importHook for the entry module and its transitive dependencies but not cause any of them to be evaluated if they haven’t been already. I am in support of having the feature, and it’s part of the Compartment proposal as compartment.load, which implies import.load(x) and import load "x" in the fullness of time. |
| 20:06 | <kriskowal> | I recall Node folks being cautious about import.meta.resolve because it increases the allocation burden to one new closure for every module that utters import.meta. I think that just pushes you more toward preload(x, import.meta.url) for a stopgap. If the feature is enshrined at TC39, it should be import.load, which is syntax and doesn’t imply a closure. |
| 20:11 | <jakobjingleheimer> | Yes, that is an issue. We have an idea how to mitigate that. For now, i think we can ignore that issue (it's kinda my problem 😉) It's most applicable to node-like, there's a tiny use-case for browsers, which is ehy i think import.meta is the place for it |
| 20:13 | <guybedford> | In general though I think we should try to aim for as a goal - does this make sense in TC39 first? If so, first explore that. If not, then WinterCG. If not, then platform-specific standards. |
| 20:15 | <kriskowal> | I am in favor import load and import.load in 262. Node.js can deprecate import.meta.load, browsers would not be able to. |
| 21:35 | <jakobjingleheimer> | Sure, we can go TC39 first 🙂 |
| 21:44 | <kriskowal> | Not to beat a dead horse, if TC39 specifies a transitively loaded import phase, I am against spelling that import.meta.load because that creates an obligation for a virtual module to add load to its importMeta, which it could either elect not to do or do with behavior that senselessly deviates from what a Module instance would do regardless of the host environment. import.meta is the purview of hosts and virtual hosts. |