Page MenuHomeSolus

Update to nodejs 9.0.0
AbandonedPublic

Authored by mariosant on Nov 5 2017, 2:43 PM.

Details

Reviewers
None
Group Reviewers
Triage Team
Summary

Async hooks: Older experimental APIs have been removed. [d731369b1d] #14414
Errors: Improvements have been made to buffer module error messages. The assignment of static error codes to Node.js error continues.
Child Processes: Errors are emitted on process nextTick.
Domains: The long-deprecated .dispose() method has been removed.
fs: The fs.ReadStream and fs.WriteStream classes now use destroy(). fs module callbacks are now invoked with an undefined context.
HTTP/1: A 400 Bad Request response will now be sent when parsing fails. Socket timeout will be set when the socket connects. A bug causing the request 'error' event to fire twice was fixed. HTTP clients may now use generic Duplex streams in addition to net.Socket.
Intl: The deprecated Intl.v8BreakIterator has been removed.
OS: The os.EOL property is now read-only.
Timers: setTimeout() will emit a warning if the timeout is larger that the maximum 32-bit unsigned integer.

Test Plan

I tested locally by running node -v and npm -v to confirm that both are found and executed.

Diff Detail

Repository
R2177 nodejs
Branch
update-to-node-9
Lint
No Linters Available
Unit
No Unit Test Coverage
mariosant created this revision.Nov 5 2017, 2:43 PM

While I understand we might want to stay on LTS, may I suggest we introduce a nodejs-current package to install the latest version? Similar to what we have for the kernel package.

While I understand we might want to stay on LTS, may I suggest we introduce a nodejs-current package to install the latest version? Similar to what we have for the kernel package.

Looks like reasonable solution +1 for this

JoshStrobl abandoned this revision.Nov 5 2017, 8:58 PM
JoshStrobl added a subscriber: JoshStrobl.

I won't be upgrading to non-LTS or introducing two versions. You're welcome to download Node Version Manager and use that to have multiple versions.

Thank you for your time @JoshStrobl .

@mariosant Just to build on this:

  1. 8.x has only recently became the active LTS and applications (namely VS Code being the first that comes to mind) are still working towards supporting it (or at least should be). While it isn't actually a lot of work (I've recently moved some code written from 6.x to 8), I don't want us getting ahead of the curve again. I would rather have a nodejs that targets what most applications are or should be written against rather than what is the current branch. While 7.x was for the most part, fine, I had to carry some patches for Atom longer than I wanted, and Google Play Desktop Music Player broke too many times to count.
  2. For developers that absolutely need multiple versions of nodejs, Node Version Manager should do the trick. I haven't landed it yet in the repo, simply haven't had the time (see T4242) and there is some work that needs to be done on gutting their script to prevent it upgrading itself, but you should actually already be able to use it from the script they provide (but don't quote me on that).
  3. Maintaining two nodejs versions isn't really reasonable or realistic. You'd have to constantly patch either nodejs or the secondary package to install modules in a separate location, patch and vendor NPM (LTS and current aren't always the same versions), and deal with any conflicts. You'd then have to patch any application that you want to run against the current branch to ensure it calls the right vendored NPM and installs any global node modules (which it shouldn't anyways, but it's a possibility that isn't too exciting) to the right versioned node_modules folder. Plus it really just goes against our policy of having multiple providers unless absolutely necessary, and a current branch as a secondary package simply isn't necessary.

Hope that's a more comprehensive answer =)

Makes sense, @JoshStrobl and I agree with the reasoning. My response wasn't sarcastic nor ironic. Apologies if it make you feel that way.

@mariosant Nah I just felt like I could've given a more comprehensive reason, so I followed-up after I had gotten out of bed :D

So we have a situation:

node.js in repo: LTS 8.9.4, not a current — 9.4.0

but...

nginx in a repo: current 1.13.7, but not a stable/LTS — 1.12.2

@virpool, I don't believe it is a problem, since there are no applications on Solus repo that are depending from it, which I believe is not the case for nodejs. In my understanding Nginx's position within Solus is to ease developers, since it (Solus as a project) does not support a server "flavor". On the other hand, nodejs is used by some of the apps in order to run and build.

If someone really needs the latest version, NVM can always be installed.

@virpool One is a language that applications rely on, another is an application. I fail to see your point.

My stance isn't changing. We're sticking to LTS. I've tried the whole "let's go with current" route and it didn't work out.