Difference from nexe? about pkg HOT 9 CLOSED

Nexe contributor here. I also built xbin as a response to enclose being closed source. Its great to see it as OSS in pkg!

Edited xbin features have been integrated into nexe

A short description of how the two projects work. (Please correct me if I missed anything)

nexe:

• Bundles the application if desired using webpack.
• Downloads node source (or a prebuilt binary)
• Adds your application bundle as a native module (like fs, http, path etc)
• Applies arbitrary source patches.
• Maybe compiles downloaded source
• Inserts bundle into pre-sized binary
• Code is run as main when executable is run (instead of the repl)

pkg:

• Bundles the application with a custom v8 script compiler into a snapshot
• Downloads the node source (or a prebuilt binary)
• Applies arbitrary source patches
• Maybe compiles downloaded source
• Appends snapshotted output to the end of the binary
• Snapshot (cachedData from v8) is loaded/run when binary executes.

from pkg.

Thanks for your comparison @calebboyd.

I'll add the following: we've been using pkg in production for a year. We decided to open source it because it's remarkably easy to use (just run pkg) and it works really well for us. We're glad to contribute to this rich ecosystem and welcome others!

from pkg.

Thanks everyone that has notted down the differences between all those projects.
Now from an user point of view, which tool is better at what ? I mean, what kind of projects targets each tool, or what kind of use-cases are better for one or another ?

regards

from pkg.

I've used all 3 tools to create binaries, each has its strength and quirks.

• node-packer/node-compiler/enclose.io is the slowest of all tools to use, it has a great advantage that you can pretty much code however you want and the app will do its best to work it out, but for a continuous release process the compile time is just a killer.

Technologically there are differences between Nexe and Pkg, but one of the features I really like with Pkg is the ability to easily add user code as plugins / modules during run-time and as I work a lot on enterprise applications this extension level is an essential feature.

.node files are just a pain with Pkg though, and yes I've tried quite a few tricks to make them simpler to integrate and manage but as they need to be in the same root as the binary I often find my users forget to include them or complain why there's an addition .node file in the base directory (as they don't care that the binary is written in node) In this sense nexe works well.

Currency is also a challenge at the moment, in that at this time of writing Pkg 8.x stream is 8.9.0 while LTS is 8.11.3 so would be great to see this automatically kept more current (I know we can build from source our-self but ...)

Other big difference for those of us using containers is that Pkg built binaries explode in Alpine Linux, so Debian is the better choice for packaging. While Nexe does support Alpine

Dynamic requires with Pkg can also be more than challenging depending on your application architecture. It took a few passes to make one of our more complex applications find a way to static require our own modules to keep the tree happy.

Pkg is without doubt my first choice for binaries and only fallback to Nexe for the specific reasons mentioned above

from pkg.

@rohmanhm Node-Compiler mentions differences in its readme -

Pkg hacked fs.* API's dynamically in order to access in-package files, whereas Node.js Compiler leaves them alone and instead works on a deeper level via libsquash. Pkg uses JSON to store in-package files while Node.js Compiler uses the more sophisticated and widely used SquashFS as its data structure.

from pkg.

How about difference between Node-Compiler https://github.com/pmq20/node-compiler

from pkg.

Would also like to know what @danielo515 asked :D

from pkg.

Absolutely agree with @keidrych. I just finished implementing pkg on my app's flow and it took me days to find what path to use where, and when. It works flowlessly now, tho.

from pkg.

The nexe capability described here of packaging .node files does not work (any longer maybe?). Takes away a big reason to switch.

#nexe/nexe#430

It would be great if at least the required .node files were put into the output directory along with the executable instead of having to hunt them down.

from pkg.