[Feature] Allow specifying alternative extraction / temporary directory

The Readme file reads:

To Where Are the Packages Uncompressed at Runtime? It depends on the operating system. You may find the location on your system with: $ node -p "require(\"os\").tmpdir()" Look for a directory named caxa in there.

Temporary directories are, well, temporary, and may get deleted when the user logs out or reboots the machine, depending on system configuration. I’d like to avoid that, to avoid the occasional performance hit which would be bad UX for end users (and might be “mysterious” to them). My app has hundreds of megabytes in node_modules and the runtime extraction time is non trivial (in excess of 10 seconds in a fairly fast machine with a SSD disk, possibly 30+ seconds in a slow machine).

• A flag of the caxa command line could allow specifying an alternative folder (other than "require(\"os\").tmpdir()"). Say, --extract-dir /usr/local/lib/myApp.
• In addition, a {{PREFIX}} string could be replaced at runtime with the value of the PREFIX environment variable, with a default value specified as {{PREFIX=/default/prefix}}.

Examples:

$ caxa --extract-dir "C:\Program Files\myApp" ...
$ caxa --extract-dir "/opt/myApp" ...
$ caxa --extract-dir "{{PREFIX=/usr/local}}/lib/myApp" ...

In the last example above, at runtime, if the PREFIX environment variable was defined and set to '/usr', then the app would be extracted to /usr/lib/myApp. If the PREFIX environment variable was not defined, or if it was defined and set to /usr/local, then the app would be extracted to /usr/local/lib/myApp.

I appreciate that extracting to a folder like /usr/local would require superuser privileges / sudo. That’s OK.

---

Rationale I was thinking of using caxa as a sort of “installer” for my app. I would set the --command entrypoint to a short JavaScript module (part of the app) that would additionally create a symlink or file at, say, /usr/local/bin/myApp that would look like:

#!/usr/bin/env sh
/usr/local/lib/myApp/node_modules/.bin/node /usr/local/lib/myApp/bin/main.js

Or some variation of this. Then running myApp on a command prompt would execute /usr/local/bin/myApp, and in turn /usr/local/lib/myApp/node_modules/.bin/node .... One could even consider that caxa could provide a standard “installer mode” feature that would do just that, but this is probably for some other feature request. 😃

“If you just want caxa to extract / install the app, why not just use a traditional installer?” Well, that’s what I’m currently doing on Windows (NSIS) and macOS (pkgbuild), but I am currently considering the options on Linux and every option I came across had some drawbacks, for example:

• .AppImage (squashfs) depends on fuse which in turn requires a Docker container to run in privileged mode.
• apt install myApp à la Spotify requires setting up repository keys and is not available on some Linux distributions.
• pkg has the complications listed in caxa’s Readme and the latest versions have some bugs related to fs promises and native node modules. I have used pkg for years but found myself spending a lot of time chasing bugs because of the modifications that pkg makes to Node.js.
• Plain shell scripts tend to snowball into large files full of corner cases depending on whether curl or wget or bash or POSIX sh or apt or apk are available, “unless it’s Arch Linux or Fedora or”… And I’d rather code in JavaScript, like the rest of the app.
• Snap and Flatpak depend on daemons / systemd / d-bus …

At which point I came across caxa and thought, “this might just do the trick!” Simple enough and universal enough, especially with the upcoming ARM support in issue #4. 😃

[TheBotlyNoob]

👍 Please Add This!

[dadiborn]

I will join that party! Me too needs that option to change Temp dir to custom one, please add this option , thank you!