[Feature] Allow specifying alternative extraction / temporary directory
See original GitHub issueThe 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 thePREFIX
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 onfuse
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 incaxa
’s Readme and the latest versions have some bugs related to fs promises and native node modules. I have usedpkg
for years but found myself spending a lot of time chasing bugs because of the modifications thatpkg
makes toNode.js
.- Plain shell scripts tend to snowball into large files full of corner cases depending on whether
curl
orwget
orbash
or POSIXsh
orapt
orapk
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. 😃
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:18 (9 by maintainers)
👍 Please Add This!
I will join that party! Me too needs that option to change Temp dir to custom one, please add this option , thank you!