Document existing SEA solutions out there

[jviotti]

As a step 0 in this WG, I propose we take some time to research and document every known existing solution to the problem of packaging Node.js applications as single executables, and document them in this repository.

Doing so would allow us to better study existing approaches, organize our notes on them, find points of contact of those projects and make sure we create something that truly solves the problem by considering every perspective.

I started by documenting the ones I personally know about: https://github.com/nodejs/single-executable/blob/master/docs/existing-solutions.md.

Please comment on this issue if we're missing or just send a PR :)

[guest271314]

Does node executable itself count as Node.js applications as single executables? Node.js does not provide download of node executable alone in releases. I wrote code to fetch() the nightly .tar.gz in the browser then extract only the node executable. I think I posted the code in the SEA thread that is origin of this repository.

[ljharb]

I don't think it counts as a single executable if you have to invoke it with specific parameters. Otherwise any zero-dependency node program could qualify merely by using -e.

[guest271314]

Technically I don't have to invoke parameters when using the node executable alone. I was actually surprised Node.js did not distribute the nightly node executable without npm, npx, et al. QuickJS, Deno, bun all provide downloads of the executable alone, without package manager, other extraneous files and folders.

[guest271314]

This is the code I wrote to fetch and extract only node executable from https://nodejs.org/download/nightly https://gist.github.com/guest271314/012441b6809f60ea542b690660ee8e0d.

For this project we can compressed the exectutable in gzip format with .gz file extension which we can decompress in the browser with Compression Streams API new DecompressionStream('gzip'); similarly we can edit the source code and compress the executable in the browser as well, for upload to a CDN or repository.

[guest271314]

I'm not sure what you're getting at.

The reason I found the PR that lead to this repository was due to the fact that Node.js does not provide a download of node executable only. We have to download npm, npx, and all the files and folders in the nightly download. In my case I only needed to executable to run as a Native Messaging host.

We should provide a means to download only the nightly node executable. That is a glaring omission from Node.js downloads, where, again, QuickJS, Deno, bun all provide archived downloads of only executables.

So, what I am getting at is single-executable has a broader meaning, to me, than solely combining the node executable with additional code in a single file.

Logically, we should first provide download of the single executable node itself.

[guest271314]

@ljharb For some context, a few months ago StackBlitz claimed to be capable of running Node.js in the browser using its WebContainer. However, the source code, as far as I know is not open source. So I set about devising a means to achieve that goal in an open source manner. Basically my idea was, using the browser alone, fetch the node executable and use existsing Native Messaging host code written in Node.js compatible style, then truncate the node existable to 0 after use; so we essentially fetch and use node executable similar to an Ecmascript import, without ever actually installing node on the target system. All we need to do is write a file named "node" on the local filesystem, set the file to executable, then we can fetch and write the file to the same folder where the 0 size "node" file exists, and is already set executable, then when we are done using node, truncate to 0 so we are not carrying around node when not in use with File System Access API, which now preserves executable permissions on a file; previously always wrote a new file and didn't preserve permissions (which we can set and unset, again, via the browser). I achieved that goal in various ways. E.g., here is node-v17.9.0-linux-x64/bin/node https://github.com/guest271314/node_executable broken up into separate files that GitHub allows uploading within its size limitations.

In theory the nightly node executable can remain separate concern, with ability to concatenate any application to the executable and run as a single file.

First though, we should provide a download of the node executable itself. Then devise ways to simply concatenate whatever Node.js specific code, or C, C++, et all we want to the executable. That can be done in the browser itself as well.

Although I vehemently disagree with the value of doing that, and think that it's a good thing that node doesn't, that topic seems wildly out of scope of this entire repo. I'd suggest opening an issue on node itself to discuss it instead.

Well, I disagree with your analysis and opinion.

You havn't provided any reasons for your opinion. Other JavaScript runtimes do that. When a developer has zero need for npm, they shouldn't be saddled with that executable.

Technically I could attach any arbitrary code to the single node executable I want right now, and just split the file at offsets whenever I see fit.

We should just be able to concatenate arbitrary code to the discrete node executable in a single file - completely without having to deal with npm whatsoever.

[guest271314]

My interpretation of that statement, and per your earlier post, node executable itself is a standalone application.

I see "Member" next to both of our usernames.

[guest271314]

You can't have Node.js applications without the node executable.

[guest271314]

Then we are talking about the same thing.

node is a Node.js application.

Yes, node itself counts

We have to have the base application capable of being appended to - as a single application.

I'm not sure what precisely you are objecting to.

[guest271314]

You can if they're bundled together

Again, I disagree with your assessment.

You can't have a Node.js application without the executable.

This repo/WG is not for single executables

Well, that is the name of the repository: #1, so you are factually incorrect.

I don't think discussions about the core code required to have an application in this realm should be excluded.

You can do what you want. I shall proceed based on my understanding of the scope of this repository.

[RaisinTen]

Hi! I agree with Jordan that this repo is not about how Node.js distributes its binaries, it's about planning and providing the required code that would enable Node.js users to distribute their Node.js applications as single-executable-applications.

I'm sorry if the repo name conveyed something else but I'm personally open to better suggestions. Do you have a better name suggestion?

[guest271314]

how Node.js distributes its binaries, it's about planning and providing the required code that would enable Node.js users to distribute their Node.js applications as single-executable-applications

Again, I think we are talking about the same thing.

How do you get to Node.js application without node executable?

You can't.

So, how does this repository plan on getting the required node executable as the base code for the Node.js application?

I would prefer to build a single Node.js application including only the Native Messaging host code that is well-suited to achieve any goal, standalone.

When I set out to do that I found that it was not a simple matter to just get the node executable to merge with the Native Messaging host.

For the nightly and all other releases, I had to fetch the entire tarball with extraneous executables that would not be used whatsoever. Hardly efficient.

That Is how I located the SEA issue.

Tell me how you intend to build single-executable Node.js applications without only existing node or cutom node executable, first? That is, you cannot have a Node.js application without node.

[Trott]

How node is distributed is (in principle at least) entirely up to the Release team. In practice, they are constrained by the Build working group and the Technical Steering Committee. But that's basically it. The subject is not in scope here.

[Trott]

I started by documenting the ones I personally know about: https://github.com/nodejs/single-executable/blob/master/docs/existing-solutions.md.

Do things like electron count here or is this discussion about CLI applications only?

[RaisinTen]

I think electron does count to an extent here because we are trying to find ways to embed Electron's app.asar file (which is the archived app source code) in the binary, so that it is possible to protect the source code by codesigning even on Windows. signtool.exe doesn't sign the ASAR file format, so users will be able to unpack it, make changes to it and repack it, thus making the application insecure.

[jviotti]

@Trott @RaisinTen I'm a bit on the fence about Electron. While the SEA work we are doing is applicable to Electron, Electron as it is now probably does not count as an SEA, given that it does not embed the ASAR into the main executable itself.

Instead of adding Electron, maybe we should just document ASAR as a VFS implementation as suggested by @RaisinTen here: #4?

[RaisinTen]

sure, done - #7

[guest271314]

So this repository is bring your own node, by any mean necessary, then combine
with any other code to make a single executable; correct?

[jviotti]

I moved this to GitHub Discussions, given that by the nature of the issue title, it will never be "done"

[viceice]

A more maintained version of vercel pkg is @yao-pkg/pkg¹

Footnotes

1. https://github.com/yao-pkg/pkg ↩