Skip to content

Latest commit

 

History

History
142 lines (123 loc) · 6.91 KB

2022-10-31.md

File metadata and controls

142 lines (123 loc) · 6.91 KB
Raw

Node.js Single-Executable Meeting 2022-09-05

Links

Present

  • Claudio Wunder @ovflowd
  • Darshan Sen @RaisinTen
  • Juan Cruz Viotti @jviotti
  • Michael Dawson @mhdawson
  • Richard Lau @richardlau
  • Tony Gorez @tony-go

Agenda

  • Inclusion of postject in the Node.js binary

    • Exposing segment names to the public API

      • Darshan: If we don't include Postject into Node.js, the name of the segment becomes a part of the interface, so changes to that will be semver-major. Hiding that behind something like node --compile will prevent that.
      • Michael: We want to support more than just one way of doing it, so that if anyone wants to inject the data in a different way, then can.

    • Single section or multiple sections

      • Darshan: Do want everything to be packed into a single section?
      • Juan: There might be a maximum size limit on the amount of data that can be loaded which might be too restrictive.
      • Michael: Most generic solution is if Postject finds you a list of sections that we were trying to load and give you the pointers to all of those.
      • Darshan: Another point is that, if we want everything to be in a single section, it would require users to pack everything into a specific format.

    • Michael: Key things to consider:

      • It might make the binary bigger.
      • We can make it non-invasive enough that people who aren't using it don't get affected.
      • Distros don't like big blobs of things that they do not know what's in there, so that's problematic for WASM.
      • Since we have a separate project, we have more flexibility, specially in the early stages.

    • Darshan: About the size and WASM part, we are trying to get rid of LIEF, so that way, we don't have to worry about the WASM part and the code size too will go down significantly.

    • Juan: There are 2 keys parts of Postject - the writing part and the reading part. Which one are we talking about including in Node.js core?

    • Michael: The reading part is not that big, so including that sounds reasonable.

    • Testing

      • Darshan: It's not possible to test the creation of Single Executable Applications on CI if we keep Postject outside Node.js because using Postject would require outbound requests, so we would need to place such a test in test/internet but that doesn't run on CI.
      • Richard: It should be possible to build Node.js without an internet connection if you have the source files locally. There are some caveats, like you can't do doc testing because that requires the installation of modules.
      • Juan: Maybe we can use objcopy as suggested in nodejs/postject#63 just for CI? However, a downside is that it won't let us create PE files on Linux or macOS.
      • Darshan: We could probably do that but it would feel like dropping support for creating binaries for other platforms on a different platform, which pkg supports currently.
      • Darshan: Another problem is that while objcopy is present by default on Linux it needs to be downloaded on macOS using brew install llvm.
      • Richard: We don't install llvm anywhere, just Xcode on macOS. If something from llvm conflicts with something from Xcode, it might be problematic.
      • Claudio: What about Windows?
      • Michael: How big is Postject?
      • Darshan: 4MB.
      • Michael: Maybe we could include Postject in the test? That way, it could be used for testing but not necessarily be a part of the Node.js binary.

    • Inclusion of the injection part in Node.js after size reduction

      • Juan: Darshan is working on getting rid of LIEF and writing the injection part on only one platform in plain JS. If we accomplish that, it's going to significantly reduce the size. Would that change something?
      • Michael: The injection part doesn't necessarily have to be a part of core but the reading part does. Having the injection part in core is more about ergonomics.
      • Darshan: A reason why the injection part shouldn't be a part of Node.js core is that if we run node --compile on macOS, it's gonna be a Mach-O binary, so creating a PE executable would require sending outbound requests to download that from somewhere, which we don't want to do.
      • Juan: How common is that?
      • Michael: You probably want to do it for multiple platforms.
      • Juan: Even if you generate all of them on Linux, you might want jobs actually testing the CLI, on multiple platforms, so why not just run pkg on all platforms?
      • Darshan: Might not always be the case because if we consider macOS ARM64, that's very rare to find, so in most cases you'll build the binary but not test it on CI.

    • Inclusion of project license and version info

      • Darshan: Should we include the LIEF license in Node.js if we are only using the reading part of Postject, just because it's a part of the Postject license?
      • Juan, Michael: No.
      • Michael: We should also add a maintaining-postject document, for instructions on upgrading, etc.
      • Juan: Should we also include the version in process.versions?
      • Darshan: There are several dependencies that don't show up in process.versions, like undici.
      • Darshan: The fuse sentinel string is also a part of Postject, so do we want Node.js to use a different string to keep things less tied?
      • Michael: Maybe use a define for that?
      • Michael: Long term, maybe we can make Postject a part of Node.js but for now we can keep it as a separate project for more flexibility.

    • Experimental warning

      • Darshan: A point that Geoffrey raised is about emitting an experimental warning. When should we do that - while compiling the SEA or while running the SEA?
      • Michael: Easiest thing is including for both but users can suppress these warnings if they want.

    • Option for users to opt out of having injectable Node.js binaries

      • Michael: Let's also place even the reading part behind a compile time flag, so that users can opt out of having this feature if they want.
      • Darshan: That can be done but how do we test both cases where this feature is enabled / disabled?
      • Michael: We can have separate jobs on Jenkins.

    • Tony: If we decide to have the read part in Node.js core and the injection side in Postject, does that reduce the scope of Postject?

    • Michael: We would need the same functionality, so it doesn't change the whole use case in anyway.

Announcements

  • Juan: Tony will start working as a co-maintainer of Postject and work on the SEA initiative soon!

Upcoming Meetings

Click +GoogleCalendar at the bottom right to add to your own Google calendar.