Does pkg supersede enclose? There appears to be a relationship between the two projects, but I see that the github repo for enclose hasn't been updated in a while. Also pkg appears to be fully open source, whereas enclose is (partially?) proprietary.
Would be useful to have an explainer on this somewhere to reduce confusion.
Also, wow this project is cool. 馃槃
Recommendation: Maybe at a brief project history section in the README.md, to eventually be included on the github pages or readthedocs site?
Looks like the use cases are copied from Enclose.
馃槃 Also checkout node-compiler with differences being,
| Project | Differences |
|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| pkg | 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. |
| EncloseJS | EncloseJS restricts access to in-package files to only five fs.* API's, whereas Node.js Compiler supports all fs.* API's. EncloseJS is proprietary licensed and charges money when used while Node.js Compiler is MIT-licensed and users are both free to use it and free to modify it. |
| Nexe | Nexe does not support dynamic require because of its use of browserify, whereas Node.js Compiler supports all kinds of require including require.resolve. |
| asar | Asar uses JSON to store files' information while Node.js Compiler uses SquashFS. Asar keeps the code archive and the executable separate while Node.js Compiler links all JavaScript source code together with the Node.js virtual machine and generates a single executable as the final product. |
| AppImage | AppImage supports only Linux with a kernel that supports SquashFS, while Node.js Compiler supports all three platforms of Linux, macOS and Windows, meanwhile without any special feature requirements from the kernel. |
if the question has been answered, why not close this issue
@amritdevilo I don't see where the initial question was answered. Do I'm missing something?
I think the answer was "yes." But I suppose it wasn't explicit. Reopening...
Most helpful comment
馃槃 Also checkout node-compiler with differences being,
| Project | Differences |
|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| pkg | 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. || EncloseJS | EncloseJS restricts access to in-package files to only five
fs.*API's, whereas Node.js Compiler supports allfs.*API's. EncloseJS is proprietary licensed and charges money when used while Node.js Compiler is MIT-licensed and users are both free to use it and free to modify it. || Nexe | Nexe does not support dynamic
requirebecause of its use ofbrowserify, whereas Node.js Compiler supports all kinds ofrequireincludingrequire.resolve. || asar | Asar uses JSON to store files' information while Node.js Compiler uses SquashFS. Asar keeps the code archive and the executable separate while Node.js Compiler links all JavaScript source code together with the Node.js virtual machine and generates a single executable as the final product. |
| AppImage | AppImage supports only Linux with a kernel that supports SquashFS, while Node.js Compiler supports all three platforms of Linux, macOS and Windows, meanwhile without any special feature requirements from the kernel. |