-
Notifications
You must be signed in to change notification settings - Fork 6
/
2022-10-31.md
142 lines (123 loc) · 6.91 KB
/
2022-10-31.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
# Node.js Single-Executable Meeting 2022-09-05
## Links
* **Recording**: https://youtu.be/Lw3cyjUofI4
* **GitHub Issue**: https://github.com/nodejs/single-executable/issues/54
## 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
https://github.com/nodejs/postject/issues/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
* **Node.js Project Calendar**: <https://nodejs.org/calendar>
Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.