Specifying node versions

[bkeepers]

Specifying an acceptable version of Node to use across a bunch of different apps running a bunch of different platfroms (Heroku, glitch, nodenv, nvm, etc) has been a pretty big hassle.

Behavior I want: all Probot apps should default to using the latest LTS release. They can override it if they need to.

Here's all the places we currently specify a node version:

• probot/template specifies a version in engines that every generated app inherits
• $ probot CLI checks engines specified in probot's package.json

There's also challenges with:

• Glitch uses engines, but doesn't understand semver: Node dependency version fix. template#44
• Each app generated from probot/template now has to keep engines up to date as it evolves. Updating Probot (e.g. with Greenkeeper) doesn't update engines
• I don't think any of the development tools (nodenv, nvm, etc) respect engines

Is there a better strategy or method for specifying node versions? Is there a way that apps can delegate to Probot for the version?

cc @gr2m @zeke @koddsson

[abhijeetps]

Just wanted to share an addition details after exploring three different CLIs.

Here's my comment on issue: wip/app#61 (comment)
Note that by updating package.json by using >=, with this, it's updating Node.js to version 9.10.1, (most recent version with latest features).

"engines": {
    "node": ">=8.3.0",
    "npm": ">=5.3.0"
  },

And by just using just node: "8", it's updating it to Node.js version 8.11.1 (most recent LTS version of Node.js version 8).

"engines": {
    "node": "8",
  },

Hope this will be helpful. I too will check some other possibilities. 😄

[zeke]

At Heroku, I built http://semver.io/ to answer this question.

$ curl https://semver.io/node/stable
9.11.1

$ curl "https://semver.io/node/resolve/?range=^8.3.0"
8.11.1

Opened a Glitch support issue about it: https://support.glitch.com/t/irregular-support-for-semver-engines/3535

[koddsson]

I know I've talked to you about it before @bkeepers but I'm still a huge fan of just installing node as a dependency.

Installing the node package will just download and place a node binary in your node_modules/ folder and then you have a guerantee that any npm scripts you run will use the binary specified.

That means that you:

• don't have to have any additional tooling
• don't have to rely on the platform you are running on to provide the correct binaries
• can update it like any other npm package and control it with semver

It's not documented a ton and I'm not sure how many people use it but if it's just downloading and executing a binary I feel like the risk is pretty low.

---

Here's I would see it working. With these changes to probot/probot (just for debugging)

diff --git a/bin/probot.js b/bin/probot.js
index fa29e7d..af28900 100755
--- a/bin/probot.js
+++ b/bin/probot.js
@@ -3,6 +3,8 @@
 const semver = require('semver')
 const version = require('../package').engines.node
 
+console.log(`You are running Node.js version ${process.version}.`)
+
 if (!semver.satisfies(process.version, version)) {
   console.log(`Node.js version ${version} is required. You have ${process.version}.`)
   process.exit(1)

and these changes to my bot but should be made to probot/template:

diff --git a/package.json b/package.json
index 3aad438..18ec228 100644
--- a/package.json
+++ b/package.json
@@ -10,6 +10,7 @@
     "test": "jest && standard"
   },
   "dependencies": {
+    "node": "^9.11.0",
     "probot": "^5.0.0"
   },
   "devDependencies": {
@@ -17,9 +18,6 @@
     "smee-client": "^1.0.1",
     "standard": "^10.0.3"
   },
-  "engines": {
-    "node" : "9.6.0"
-  },
   "standard": {
     "env": [
       "jest"

I cannot run the bot with the wrong version:

☁  eslint-disable-bot [master] ⚡ n 6
☁  eslint-disable-bot [master] ⚡ node --version
v6.14.1
☁  eslint-disable-bot [master] ⚡ npm start

> eslint-disable-bot@1.0.0 start /Users/koddsson/koddsson/eslint-disable-bot
> probot run ./index.js

You are running Node.js version v9.11.0.

---

I was going to try to set up a small app on glitch but this method doesn't seem to work on their so maybe this isn't such a good solution.

Here's the app if you wanna take a look: https://abiding-coast.glitch.me/

I'd be interested in seeing if other platforms fail on this as well.

📚Previous work

probot/template#45

Welcome to Glitch!

A cool thing made with Glitch

[zeke]

Getting closer: https://support.glitch.com/t/irregular-support-for-semver-engines/3535/4?u=zeke

Glitch Support

Irregular support for semver engines

I took a look at semver-compare, and that’s definitely the cause of the issue. That module is designed to “compare two semver version strings”, not ranges. I think the glitch package manager would be better off using the semver module, specifically semver.maxSatisfying(versions, range), which returns the highest version in a list of node version numbers that satisfies the given range. See https://github.com/npm/node-semver#ranges-1

[stale]

Is this still causing friction? If so, please comment with any updates or addition details.

[zeke]

Gave it a nudge: https://twitter.com/zeke/status/1008566309955592193

Twitter

Zeke Sikelianos on Twitter

“@glitch it would be cool if you had semver-compliant version range resolution. Yes this is kind of niche, but important and maybe not so hard to fix.

https://t.co/Ld0WXnHkay”

[stale]

Is this still causing friction? If so, please comment with any updates or addition details.

[zeke]

Hello @Stale. Yes, still causing friction this is.

[stale]

Is this still causing friction? If so, please comment with any updates or addition details.

[zeke]

Yep, still fricative.