| 00:27 | <leobalter> | as I missed the discussions about ShadowRealm yesterday, some async comments post reading the meeting notes. For clarity and for the records, I no longer speak as a champion of the proposal, but as a regular delegate. It seems the only real blocker for Stage advancement is getting agreement from DOM vendors, which I agree. I don't think - and I hope I'm right - that stage 2.7 or stage 3 would change how DOM vendors would react or accept the proposal. The challenge for DOM vendors to accept is having the design (resolved), tests (resolved), and capacity for implementation. I don't think DOM vendors would be able to prioritize or willing to implement it just for the sake of releasing a new feature. I believe this one is up to the champions finding sponsorship for the implementation. That's something I no longer control or can exercise much leverage. Given all the facts and where we are at with ShadowRealm, offering funding for implementation of ShadowRealm is the best chance to get it accepted, and then yes, move it up to stages 3 and 4. This may still require vendors spending some cycles on review, but I think it's doable. cc ptomato dminor shu Michael Saboff |
| 02:01 | <ljharb> | it doesnโt, only immerโs maintainers |
| 14:36 | <dminor> | I don't think the problem is capacity for implementation but rather that people remain unconvinced that ShadowRealm is a good idea for the web. In that case, even if the implementation of ShadowRealm was externally funded, there's no guarantee that patches would be reviewed and landed. |
| 16:58 | <Devin Rousso> | i unfortunately am likely gonna miss plenary today and tomorrow ๐ญ but something i wanted to just throw out there regarding error stacks rather than trying to standardize (or at least codify) what already exists, what if we created a new to be clear this wouldn't preclude engines from having their own instead it would give an opportunity for all of us to agree on at least some minimal meaning for "what does a stack look like?" and "how do i get one?" |
| 17:07 | <snek> | is TLA considered harmful at this point |
| 17:08 | <ljharb> | ๐๏ธ๐ซ๐งโ๐ |
| 17:09 | <snek> | you mean standardized string, or standardized structured data? |
| 17:09 | <snek> | if the former, why? |
| 17:20 | <Chris de Almeida> | PSA: we will be ending for the day at the break. no afternoon session today |
| 17:29 | <Richard Gibson> | cf. https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$3kN3Fbul5yr4xdcqDvHKLhEzv9fQrgow7d_JyqG48_c / https://matrixlogs.bakkot.com/TC39_Delegates/2024-12-03#L118
|
| 17:32 | <keith_miller> | Sorry I missed some of this. Is import.sync + source modules insufficient for Node.js? Or is evaluation not going to permitted in import.sync if you already have the source? |
| 17:33 | <nicolo-ribaudo> | What's insufficient is if import.sync("./a/file.js") throws for a non-already-imported file |
| 17:36 | <leobalter> | I understand maintenance is also a concern, but I believe we went through years of cycles on how realm access would be good for the web. ShadowRealm is the form that was proposed using direct feedback from vendors and it still resolves the business proposition. |
| 17:37 | <leobalter> | we don't need to rediscuss this here, we can agree to disagree. It should be up to the champions to move the proposal forward. |
| 17:39 | <keith_miller> | For what reason? Because it's not possible to know all the files users want to import? Otherwise the bundling pass could just gather all the imports and replace import.sync("./a.js"); with a prepass that exposes a bunch of aSourceModules and does import.sync(aSourceModule) |
| 17:42 | <nicolo-ribaudo> | There is no bundling pass in Node.js, it runs modules directly. The use cases for import.meta.require("./a/file.js") is synchronous conditional loading, for example to only load a polyfill when running in Node.js and not when running in the browser |
| 17:50 | <Ashley Claymore> | some of which could be done with an import map? Though I guess a library can't easily 'ship' an import map that it expects the final app to pull in |
| 17:50 | <Ashley Claymore> | would have to express via package.json |
| 17:50 | <keith_miller> | Sure, I guess I was thinking of package.json as the "bundling pass" |
| 17:52 | <keith_miller> | It seems like it wouldn't be crazy or insurmountable to specify all the conditional packages your project uses in package.json. Or if you do some sync importing for some other package to require that package to list the ones it uses |
| 17:52 | <keith_miller> | That would be a good security practice anyway, IMO |
| 17:54 | <keith_miller> | Perhaps there's some details I'm missing though |
| 17:54 | <nicolo-ribaudo> | So, assuming that they are all in package.json (I was assuming the same), then what happens? Are you assuming that Node.js loads all the dependencies defined in package.json at startup, so they then they are already pre-loaded when you try to sync import them? |
| 17:55 | <keith_miller> | Yeah, effectively. |
| 17:55 | <keith_miller> | If it's just an fopen call at sync import time that's probably sufficiently equivalent from a spec compliance PoV |
| 17:56 | <nicolo-ribaudo> | Well, it also requires parsing to recourse into the dependencies of the modules you list as dependencies in package.json |
| 17:57 | <nicolo-ribaudo> | This solution seems fine, but then it's equivalent to "we allow Node.js to have different behavior from browsers" |
| 17:57 | <nicolo-ribaudo> | Since browsers don't pre-load the import map |
| 17:57 | <keith_miller> | Why would have to parse the source? It seems like that data should be transitively visible from the package.json |
| 17:58 | <nicolo-ribaudo> | package.json dependencies point to a "group of modules". Only the entrypoints of each library are listed |
| 17:59 | <nicolo-ribaudo> | Not the modules they load within the same package |
| 17:59 | <keith_miller> | Yeah but those entrypoints also have a package.json(?) So that would tell you what modules are needed for that package, recursively |
| 18:00 | <ljharb> | not necessarily, because package.json doesn't have to list every entrypoint unless it's using exports |
| 18:00 | <ljharb> | also, even with using exports, each entrypoint could be importing other relative files that aren't externally accessible |
| 18:00 | <nicolo-ribaudo> | also, even with using |
| 18:01 | <nicolo-ribaudo> | If you have a dependency my-lib that has entrypoint ./a.js, and ./a.js imports ./b.js within my-lib, ./b.js is not listed in the dependencies of my-lib |
| 18:02 | <nicolo-ribaudo> | Because dependencies are packages, not individual modules |
| 18:02 | <keith_miller> | Is that fundamental? Couldn't during their import.sync transition they add a new field to package.json that's all the private modules? |
| 18:03 | <ljharb> | there's no way to mandate that |
| 18:03 | <nicolo-ribaudo> | Well it could |
| 18:03 | <keith_miller> | Sure, import.sync fails if you don't add the field lol |
| 18:03 | <ljharb> | it's a language syntax feature |
| 18:04 | <ljharb> | node has no ability to make it fail |
| 18:04 | <ljharb> | but also, the number of people who would want to do that rounds to zero |
| 18:04 | <nicolo-ribaudo> | Well it can fail the same way as it can fail in browsers |
| 18:04 | <keith_miller> | Node has the ability to not provide the source module if you don't specify it? |
| 18:04 | <ljharb> | that requirement would basically guarantee nobody adopts it |
| 18:04 | <keith_miller> | Wild... |
| 18:05 | <keith_miller> | It could be done by node for you even lol |
| 18:05 | <nicolo-ribaudo> | I think what keith_miller proposes would work, but it's effectively like saying that Node.js and browsers can diverge? Node.js could just say "we pre-load all the files we find in the folder" |
| 18:05 | <keith_miller> | or some other script |
| 18:05 | <ljharb> | node definitely should never be modifying package.json, and if it's done by a script then i'd have to run that every time i add or remove a file inside the package |
| 18:05 | <keith_miller> | I mean Node.js is completely allowed to put whatever source modules it wants into some namespace? |
| 18:06 | <ljharb> | i'm not sure what you mean by "allowed" |
| 18:06 | <ljharb> | node can do anything. what it could do that would be deemed acceptable is a much smaller list |
| 18:07 | <ljharb> | and forcing me to change package.json every time i make a small refactor to extract something to a file, or rename/move a file, is an insanely onerous ask |
| 18:07 | <ljharb> | even if it's automated, the git diff churn is prohibitive |
| 18:07 | <keith_miller> | What in the TC-39 spec prevents node from lsing your directory and providing a bunch of variables in your module via import.meta or something? |
| 18:07 | <ljharb> | nothing |
| 18:08 | <ljharb> | but node doesn't just have ESM, they also have CJS, and import.sync would presumably work in CJS (Script) also, just like import() does |
| 18:08 | <keith_miller> | Great then it doesn't even need to be in the package.json |
| 18:08 | <ljharb> | i doubt the performance of that would be something node would ever want to implement, hitting the filesystem is expensive |
| 18:09 | <ljharb> | put another way, we could have made ESM fully sync, and browser devs would have been required to use a tool to generate a complete list of imported modules up front. would that be acceptable DX to you for browser devs? it seems like that's what you're asking for here. |
| 18:09 | <nicolo-ribaudo> | Is it observable wether Node.js does that eagerly upfront or lazily as needed, other than performance? |
| 18:10 | <keith_miller> | I don't think so |
| 18:10 | <ljharb> | yes, because the fs isn't static, and the program (and the rest of the machine) can make changes to it |
| 18:10 | <keith_miller> | Other than for reasons outside of TC-39's control |
| 18:10 | <ljharb> | "the filesystem" is a concept that doesn't exist in tc39 :-p |
| 18:12 | <keith_miller> | This API could just be a window proxy like object that vends you back the source module for the file you specify synchronously? |
| 18:12 | <keith_miller> | Or just a function |
| 18:12 | <ljharb> | also, that would be effectively a discouragement of having many small files, which would definitely be bringing us back to "all the code is in one file" (referencing a TDZ discussion) |
| 18:12 | <snek> | how does this coalescing work, is relative resolution not preserved in module sources? |
| 18:12 | <keith_miller> | So you'd just do import.sync(nodeJSSpecificThingThatFindsYourSourceModule("./a.js")) |
| 18:12 | <ljharb> | like even if there were no technical issues with it, i don't think enumerating files is a viable path |
| 18:13 | <ljharb> | "./a.js" is your source module tho, it's a file path |
| 18:13 | <snek> | oh the specifier is part of the key ok |
| 18:13 | <ljharb> | and since that node-specific thing wouldn't exist in browsers, that wouldn't get us to the goal of being able to write universal code |
| 18:13 | <ljharb> | (with import maps, file paths work fine in browsers) |
| 18:14 | <keith_miller> | Then nodeJSSpecificThingThatFindsYourSourceModule could be nodeJSSpecificThingThatFindsYourSourceModule(a) { return a; } in browsers? |
| 18:14 | <keith_miller> | Presumably with a different name lol |
| 18:16 | <nicolo-ribaudo> | Can nodeJSSpecificThingThatFindsYourSourceModule be called import.meta.resolve? ๐ |
| 18:16 | <keith_miller> | I'm just saying Node.js has workarounds to specifying everything up front. For browsers 99% of devs do bundling so that seems like it could handle gathering this data for them. |
| 18:17 | <nicolo-ribaudo> | I'm just saying Node.js has workarounds to specifying everything up front. For browsers 99% of devs do bundling so that seems like it could handle gathering this data for them. import.sync working automatically in Node.js due to Node's magic, but not in browsers without extra user work? |
| 18:17 | <keith_miller> | Personally, sure |
| 18:17 | <ljharb> | lol, a lot of devs on social media got very angry about the implication that 99% of devs use bundlers and that the language should build in that assumption |
| 18:18 | <keith_miller> | They don't have to use bundlers but then they have to do their own bookkeeping |
| 18:18 | <ljharb> | if it's onerous without a tool, then a lot of folks will be angry about it |
| 18:18 | <keith_miller> | So we should make everyone's experience bad? |
| 18:18 | <Ashley Claymore> | Should the language build in that we also minify? |
| 18:18 | <ljharb> | no, we should be designing so tools can work, but not designing assuming users have to use the tools |
| 18:19 | <keith_miller> | Then, IMO, we'll likely have nothing |
| 18:19 | <keith_miller> | And Node.js will end up doing it's own thing |
| 18:20 | <ljharb> | that may indeed be the case |
| 18:20 | <ljharb> | that's what we'll explore in stage 1 |
| 18:20 | <keith_miller> | That seems worse than providing something which works for most folks, IMO |
| 18:22 | <keith_miller> | I agree we should aim to provide things that work without tools but I don't think we should let that be the enemy of good |
| 18:22 | <ljharb> | you may be overestimating how many users use bundlers, is all |
| 18:22 | <ljharb> | (unless you have actual data on that, which would be very valuable to have publicly but doesn't exist afaik) |
| 18:30 | <nicolo-ribaudo> | Chairs, I would prefer that we disallow saying "you can jump in in my presentation", because it's very difficult for others to interact |
| 18:31 | <nicolo-ribaudo> | I either have the choice to jump in all the time too, or add myself to the queue for after this back-and-forth is done and we are three topics past it |
| 18:32 | <bakkot> | you may be overestimating how many users use bundlers, is all |
| 18:34 | <Chris de Almeida> | there's something to be said for the importance of timely clarifications -- meaning while we're on the slide, rather than waiting till the end. so I think it's ok if the presenter wants to do that. but to your point, it is better if we say to still use clarifying question in TCQ, with the understanding that the chairs will interrupt immediately during the presentation in this mode |
| 18:35 | <nicolo-ribaudo> | Ok that seems like an ok approach, if chairs would facilitate in that way |
| 18:35 | <nicolo-ribaudo> | Ideally we should encourage presenters to keep an eye on the queue while presenting, but I understand that it can be difficult |
| 18:40 | <nicolo-ribaudo> | Kris Kowal I think I disagree with the idea that we need to pass hook to the source constructor. Instead, I'd like to have module instances being implicitly created from sources by inheriting the same options bag from the referrer module instance |
| 18:40 | <nicolo-ribaudo> | Effectively, the hook are only defined in the entry point of the graph |
| 18:41 | <nicolo-ribaudo> | And they have to receive the referrer source (which has (virtual-)host-specific metadata, such as the base URL) as an argument to do proper resolution (I liked seeing it unexpectedly in the slides) |
| 19:04 | <snek> | did the meeting end or is it lunch? |
| 19:04 | <snek> | oh i see the calendar was just edited, nvm |
| 19:04 | <nicolo-ribaudo> | end |
| 22:35 | <Chris de Almeida> | PSA: barring any late additions/requests for continuations, if we don't make up any time tomorrow, we are going to ask that we continue the meeting for 15 minutes into the scheduled lunch break to close out the meeting. (this avoids taking an hour break only to come back for 15 minutes) |