Collaboration with the Loaders Team #41
Replies: 4 comments 12 replies
-
Let's do it @GeoffreyBooth @RaisinTen ! At Postman, we are very interested in making this happen both in the context of SEAs and Electron. Is there a clear approach we want to go for? If so, let's start planning how we can join resources and make it happen. If not, it'd be worth arranging some discussions to figure out a solid approach. |
Beta Was this translation helpful? Give feedback.
-
Hey folks. In https://github.com/nodejs/loaders there have been a few side discussions of virtualized filesystems: It’s been of interest to @arcanis and the Yarn team, as Yarn Plug-n-Play is essentially a monkey-patched Monkey-patching is less possible with ESM code and with As far as I’m aware (@arcanis can correct me), no one’s done any design work on what such potential “customization APIs” might look like. If your team has the bandwidth to devote some time into that, I think such work would be very welcomed. We could also create a new team and repo to organize this effort, leaving “loaders” as the customization API specific to module loading and just one of several customization APIs that Node provides. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the links @GeoffreyBooth ! I'll paste some notes that I found interesting from them here, so the people don't have to go read the entire thing
This is a cool way of thinking about it. If you control the loader, you can i.e. intercept require/imports to the entire Renaming the loaders repo to broaden its scope and consider use cases like
I like this model. We should be doing this for supporting VFS'.
This hooks mechanism would play nice with SEAs. As I think somebody mentioned already, we can inline these arguments on the binary, and pass through that medium the implementation for the VFS, which would touch |
Beta Was this translation helpful? Give feedback.
-
@GeoffreyBooth One interesting twist to the problem that we are considering in the context of SEAs, is how to support a VFS implementation (through hooks or monkey patching) injected on the Node.js binary itself, that would still allow native add-ons that do read operations still work OK, or at least have a way to re-write their read operations to use a native API that is VFS-aware. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We had a brief discussion about how we imagine the VFS to be implemented in Node.js in the TSC meeting today - https://www.youtube.com/watch?v=SykIJ0p2Yb0. It seemed like a lot of the work the Loaders Team is doing is very close to what we are doing here regarding the VFS, so I proposed that the Single-Executable team should collaborator with the Loaders Team and @GeoffreyBooth seemed to be +1 about the idea!
The general consensus was that supporting monkey-patching is a bad idea because ESM is probably not going to support it. We should definitely find other ways.
Some context for @GeoffreyBooth, we are having some ongoing discussions in #37 regarding how we think the VFS should be implemented. Feel free to chime in there if you have opinions about any of the mentioned approaches!
Let's discuss how we can collaborate further in this thread. Should we have a cross-team meeting? Maybe a joint discussion in the Collab Summit? What does everybody think?
cc @nodejs/single-executable @nodejs/loaders
Beta Was this translation helpful? Give feedback.
All reactions