We're on a very old version of Node in production (v9.4.0).
Node 10 uses a new version of OpenSSL which fixes #2812. Node 12 was released this week and we're testing on that. We may as well make the leap all the way there.
It would be nice to move toward a server-provisioning and deployment process that facilitates keeping the Node and npm versions more readily up to date. If we do adopt a new process, it could address some other long-standing issues:
- We can't easily adjust our scale because this process is manual and bottlenecked on a single person.
- The lockfile is ignored (#1988).
- The production server unnecessarily installs the dev dependencies, making the deploy process take longer than necessary.
paulmelnikow
All 4 comments
We should probably prioritise this sooner rather than later. Node 9.4.0 is almost two years old at this point. It's blocking one of our pull requests, #4405, and as support for Node 8 is being dropped at the end of the month, I would expect more and more packages to require at least Node 10+.
With our current process, can other people help out with this, or is it just a matter of someone who has machine access to manually update each one of the production servers?
PyvesB
on 9 Dec 2019
I'm concerned about the old Node version too. Both that it's old, and that we can't easily control it. Also the old npm version means #1988 is still a problem, which is fairly serious.
Thadd茅e is the only one with access. There's an old conversation in the #ops Discord (I think it's #ops?) as he was starting to set up a fourth server. There wasn't an obvious way to upgrade Node on the server without also updating a bunch of other system dependencies. It seems like building new servers was the cleanest way to do this under the current architecture.
I have a draft of a proposal to move the hosting to Heroku, where we have a big service credit waiting for us. In Heroku we can bump the node version via package.json and easily test it in a PR or in staging. Plus deploys could be delegated to a subgroup of the maintainers and wouldn't be bottlenecked on me.
Maybe it's a good time to revive that proposal.
paulmelnikow
on 10 Dec 2019
Maybe it's a good time to revive that proposal.
Indeed, probably a good time. CC @espadrine
PyvesB
on 10 Dec 2019
This is resolved via #4929. Production is now running Node 10.20.1.
See also #4977.
馃槍
paulmelnikow
on 29 Apr 2020
Related issues
calebcartwright
路
3Comments
irgolic
路
3Comments
salaros
路
3Comments
techtonik
路
3Comments
AlexWayfer
路
3Comments
Most helpful comment
I'm concerned about the old Node version too. Both that it's old, and that we can't easily control it. Also the old npm version means #1988 is still a problem, which is fairly serious.
Thadd茅e is the only one with access. There's an old conversation in the #ops Discord (I think it's #ops?) as he was starting to set up a fourth server. There wasn't an obvious way to upgrade Node on the server without also updating a bunch of other system dependencies. It seems like building new servers was the cleanest way to do this under the current architecture.
I have a draft of a proposal to move the hosting to Heroku, where we have a big service credit waiting for us. In Heroku we can bump the node version via package.json and easily test it in a PR or in staging. Plus deploys could be delegated to a subgroup of the maintainers and wouldn't be bottlenecked on me.
Maybe it's a good time to revive that proposal.