|
22 | 22 | * How are native addons going to interact with the VFS? [#29](https://github.com/nodejs/single-executable/discussions/29) |
23 | 23 | * ; |
24 | 24 |
|
| 25 | +## Notes |
| 26 | + |
| 27 | +During this call, most of the discussions revolved around the problem of |
| 28 | +designing a general Virtual File System that would fit every necessary use |
| 29 | +case, ranging from compression support, native add-on interoperability, etc. |
| 30 | + |
| 31 | +The key conclusion from the call is that designing a truly universal VFS that |
| 32 | +checks all the boxes that we care about and the ones that are probably unknown |
| 33 | +so far is not trivial. For this reason, we will attempt to make VFS |
| 34 | +user-defined for the SEA MVP. That way, we will have a better sandbox to play |
| 35 | +with VFS', see what people come up with and eventually bring back these |
| 36 | +learnings to the SEA project without getting indefinitely stuck at the VFS |
| 37 | +phase. |
| 38 | + |
| 39 | +To accomplish this decoupling, we hope to: |
| 40 | + |
| 41 | +- Provide hooking capabilities to Node.js to allow developers to extend |
| 42 | + `require()`, `fs` and related key components of Node.js to support arbitrary |
| 43 | + virtual file systems without monkey-patching these modules like i.e. |
| 44 | + Electron, Yarn and PKG do at the moment. |
| 45 | + |
| 46 | +- Fix remaining issues on the Resource Injector current implementation |
| 47 | + (https://github.com/postmanlabs/postject) for injecting multiple sections of |
| 48 | + data. One of these sections will contain the VFS byte-stream, and the other |
| 49 | + one will contain the bootstrap script that can be injected to `teach` Node.js |
| 50 | + about the VFS of choice. |
| 51 | + |
| 52 | +Once we have a better grasp on what the ideal VFS should look like, we will |
| 53 | +attempt to ship the SEA project with a blessed VFS implementation. |
| 54 | + |
| 55 | +We also touched on what the definition of "Single Executable Application" |
| 56 | +means. Does it mean we will go out of our way to package every Node.js |
| 57 | +application as a single file (embedding native add-ons, etc on the executable |
| 58 | +itself)? Does an app that consists of the main executable along with sibling |
| 59 | +".node" shared libraries still qualifies as a SEA? Clearly defining what an SEA |
| 60 | +is (and is not) is key for identifying the core constrains for the ideal VFS |
| 61 | +implementation later down the road. |
| 62 | + |
| 63 | +## Action Items |
| 64 | + |
| 65 | +- [ ] Make defining user-land VFS' feasible (given the plan outlined above) |
| 66 | +- [ ] Define and document what SEAs really mean |
| 67 | + |
25 | 68 | ## Upcoming Meetings |
26 | 69 |
|
27 | 70 | * **Node.js Project Calendar**: <https://nodejs.org/calendar> |
|
0 commit comments