Skip to content
This repository has been archived by the owner on Nov 21, 2023. It is now read-only.

Don't package node with the final app #16

Closed
btarg opened this issue Apr 11, 2021 · 4 comments
Closed

Don't package node with the final app #16

btarg opened this issue Apr 11, 2021 · 4 comments

Comments

@btarg
Copy link

btarg commented Apr 11, 2021

Caxa should instead download the correct NodeJS version if it is not already installed on the system. Otherwise, it should run the version that is already installed.

The binaries for v14.16.1 (win x64) are located here: https://nodejs.org/dist/v14.16.1/win-x64/

This will help with the ridiculous file sizes.

@fcastilloec
Copy link

This is a duplicate of #9
Also, the ability for caxa to fetch the binary when extracting/running your package app, it's not the best idea.

@papb
Copy link

papb commented May 18, 2021

@iCrazyBlaze Your suggestion should at most be an option not applied by default. I prefer large file sizes than network traffic for example.

@leafac
Copy link
Owner

leafac commented May 18, 2021

@iCrazyBlaze: Thanks for the suggestion. I can think of three possible interpretations for what you said:

  1. Download the node executable when running caxa to produce the binary. If that’s the case, then we already have Option to not package node #9 which covers this.
  2. Don’t include the node executable in the binary produced by caxa, and let the binary produced by caxa download the node executable when it’s called. It’s a nice idea in principle, because it’d reduce the size of the binary produced by caxa, but I think it’s a false economy: you’re only delaying one part of the download. And it has other consequences that I think may be bad, for example, your binary wouldn’t work if you’re offline.
  3. Similar to interpretation 2, but this time we also share the same node executable among different binaries produced by caxa, instead of downloading the same node executable over and over. This is nice because it’ll consume less space on the user’s machine. It’s a true economy. But it comes with the same caveat of offline use, and it’s a more complex setup, one in which caxa would be responsible for managing node installations on the user’s machine. I think that Electron is going in this direction. I like the idea in principle, but I don’t think we’re going there just yet. For now, let’s stick to the paradigm of “download this binary and everything will just work” (even if you’re offline by the time you run it).

In summary, I really appreciate the idea but I’m closing this for now. If there’s something I’m missing, please reopen and we’ll talk about it.

@leafac leafac closed this as completed May 18, 2021
@leafac
Copy link
Owner

leafac commented Jun 13, 2021

Some updates: In version 2.0.0 there are advanced command-line options that allow you to customize the build, and you may achieve what you want using these options as part of a more sophisticated build process.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants