Node.js Single-Executable OpenJS Mini-summit 2022-10-01

Present

• Michael Dawson @mhdawson
• Darshan Sen @RaisinTen
• Juan Cruz Viotti @jviotti
• Claudio Wunder @ovflowd
• Ruy Adorno @ruyadorno
• Orta Therox @orta
• Tierney Cyren @bnb
• Tobias Nießen @tniessen
• Tony Gorez @tony-go
• Anton Whalley @No9
• Waleed Ashraf @WaleedAshraf

Notes

• There is general agreement that we want to try as hard as possible to make SEAs truly "single executable" without additional resources
• There is agreement that we don't want Node.js to support a single specific blessed VFS. Instead, Node.js should aim to provide the necessary hooks for supporting arbitrary VFS implementations
• Teaching Node.js how to transparently work with a VFS on fs, require, import and child_process is non-trivial. We agreed that we do not want implementations to continue monkey-patching these modules and that monkey-patching will not work with ESM at all
• Exposing hooking capabilities is a complex problem. While we agree that a VFS is essential for supporting dynamic requires, read operations, etc we believe that there is a significant number of Node.js CLIs that might not need this
• Therefore, we can explore delivering an MVP without a VFS while we continue thinking about how we'll do VFS properly
• This MVP would assume that apps are bundled into a single JavaScript file before injection
• Node.js core would take a small patch to detect a single file embedded as a section and jump to it if found
• In the interest of making Node.js binaries smaller without operating custom Node.js builds, we will move the ICU data into a new section, so it can be replaced by the ICU "small" data (or removed?) if needed post-compilation rather than at build-time
• We expect that distributing Node.js injected binaries to user computers will come with challenges we want to solve in advance. For example, Windows PE binaries including plain JavaScript tend to be flagged by AntiViruses as trojans. We will start maintaining a list of these challenges and then try to figure out how to incrementally solve them.

Action Items

• Send patch to https://github.com/nodejs/node to detect and jump to a section containing a single JavaScript file if found (https://github.com/nodejs/single-executable/issues/47)
• Collect a list of potential problems we would face when distributing Node.js injected binaries to user computers across operating systems (https://github.com/nodejs/single-executable/issues/46)
• Split Node.js ICU data into its own section (so we can fiddle with it with Postject) (https://github.com/nodejs/single-executable/issues/48)
• @No9 to connect us with IBM AIX folks to understand the need for SEAs on AIX (and potential XCOFF help?)
• Start working on a proper "SEA" CLI MVP that can bundle and inject simple Node.js applications (https://github.com/nodejs/single-executable/issues/49)

Other Ideas

• We could explore splitting different Node.js modules (like fs) into separate sections to strip them out for applications that do not need them
• We could explore a different mechanism for loading native add-ons in order to embed them into the executable itself. For example, marking the corresponding sections as readable + executable and doing a long jump to the instructions corresponding to the add-ons instead of using dlopen, etc