Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

additional build size flavours #19307

Closed
devsnek opened this issue Mar 13, 2018 · 5 comments
Closed

additional build size flavours #19307

devsnek opened this issue Mar 13, 2018 · 5 comments
Labels
build Issues and PRs related to build files or the CI. discuss Issues opened for discussions and feedbacks.

Comments

@devsnek
Copy link
Member

devsnek commented Mar 13, 2018

spinning off of #19214, i wanted to brainstorm here about possibly providing build size goals for each release, more installer options, etc

feel free to edit this list

some sizes:

  • Normal

    • full icu
    • local HTML documentation
  • Small

    • small icu
    • no debug symbols
    • maybe minify js source, unsure of how much space that would save if any and would be killing useful stack traces
  • Large

    • full icu
    • local HTML documentation
    • debug symbols
    • additional compression algos, websockets?
    • whatever is highly standardised but not specific enough to go in normal node builds

other ideas

  • using installer to include more stuff
    • local documentation
    • additional "core" modules (additional compression algos, websockets) (loadable via dlopen/require from some location?)
      • vetted and maintained by node team, intended to work in core like any other builtin, kept in main repo, same testing, etc etc
@vsemozhetbyt vsemozhetbyt added discuss Issues opened for discussions and feedbacks. build Issues and PRs related to build files or the CI. labels Mar 13, 2018
@Trott
Copy link
Member

Trott commented Mar 13, 2018

Nit: Maybe instead of Normal, use the term Standard? (Or maybe Recommended?)

@bnoordhuis
Copy link
Member

I'll be today's Devil's advocate!

Paradox of choice: the more available options, the more anxious people get. Let's not inflict that on our users, most already have a hard enough time wading through the npm morass.

@gibfahn
Copy link
Member

gibfahn commented Mar 15, 2018

Paradox of choice: the more available options, the more anxious people get. Let's not inflict that on our users, most already have a hard enough time wading through the npm morass.

I agree, but I think having sensible defaults is a good mitigation for that. As long as the one you get presented with when you go to nodejs.org (or run nvm install) is the one we think most people will want, then only those who care enough to look will have the choice.

Doing twice as many builds is of course a lot of overhead for @nodejs/build and @nodejs/release

@joyeecheung
Copy link
Member

joyeecheung commented Apr 2, 2018

How many people that need a non-normal build actually use the official installers? My guess is we could just provide such builds to download, and whoever wants those can grab it by themselves and install it on their own, they can send feature requests to nvm of course.

@devsnek
Copy link
Member Author

devsnek commented Apr 22, 2018

seems stalled and like what we have currently is good enough... can be reopened if needed

@devsnek devsnek closed this as completed Apr 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. discuss Issues opened for discussions and feedbacks.
Projects
None yet
Development

No branches or pull requests

6 participants