Discussion: Unify/solidify Node.js support

[rarkins]

Node.js support is still not where I'd like it to be, so I'm creating this issue to bring all topics together and hopefully work out a plan.

Node.js can be updated in:

• package.json > engines
• package.json > devDependencies
• .nvmrc
• .travis.yml : often multiple versions, easy to parse
• .circleci/config.yml : also often contains multiple versions, difficult to parse because there's no convention for how multiple versions are included
• Dockerfile
• docker-compose.yml

In addition:

• There is @types/node that we want to keep in sync too
• Docker node versions may be like foo/node if people build their own custom one

The main difficulty is trying to guess if people actually want their Node.js updated to next major versions or not.

The second difficulty is handling when certain package files contain multiple versions (e.g. Travis). To help with that, we have supportPolicy defined but it isn't really used widely.

Finally, for now we disable major updates to node and */node packages.

[rarkins]

Here are some easy requirements:

• If the user defines an exact (pinned) version of node in any of these files, then we submit PRs whenever there are minor or patch versions available

• If rangeStrategy=pin then we should pin the node version in any of the files if it is currently a range (including 8, 8.10, etc). This partly depends on range pinning in each package manager though.

• If supportPolicy is defined then we set Travis versions to that

• If supportPolicy is defined then we should major upgrade pinned versions in package.json and .nvmrc to match the highest version. We can do that because they support only one Node.js version anyway

Not easy ones:

• package.json > engines might be something like >= 6. If they define supportPolicy to be LTS then they probably don't want that to be changed until Node.js 6 is no longer supported.

• CircleCI and Docker Compose files can often have multiple versions of Node.js - especially CircleCI because it's used for testing. For Docker Compose and Dockerfile we can probably default to assuming only one version in the files, so long as we make it configurable.

[rarkins]

A reminder of LTS schedule:

{
  "v4": {
    "start": "2015-09-08",
    "lts": "2015-10-12",
    "maintenance": "2017-04-01",
    "end": "2018-04-30",
    "codename": "Argon"
  },
  "v5": {
    "start": "2015-10-29",
    "maintenance": "2016-04-30",
    "end": "2016-06-30"
  },
  "v6": {
    "start": "2016-04-26",
    "lts": "2016-10-18",
    "maintenance": "2018-04-30",
    "end": "2019-04-01",
    "codename": "Boron"
  },
  "v7": {
    "start": "2016-10-25",
    "maintenance": "2017-04-30",
    "end": "2017-06-30"
  },
  "v8": {
    "start": "2017-05-30",
    "lts": "2017-10-31",
    "maintenance": "2019-04-01",
    "end": "2019-12-31",
    "codename": "Carbon"
  },
  "v9": {
    "start": "2017-10-01",
    "maintenance": "2018-04-01",
    "end": "2018-06-30"
  },
  "v10": {
    "start": "2018-04-24",
    "lts": "2018-10-01",
    "maintenance": "2020-04-01",
    "end": "2021-04-01",
    "codename": ""
  },
  "v11": {
    "start": "2018-10-23",
    "maintenance": "2019-04-01",
    "end": "2019-06-30"
  }
}

Meaning:

• 5, 7 and 9 were never LTS and are now completely unsupported
• 4 was LTS but is now unsupported
• 6 is LTS but now in maintenance. will be unsupported on 2019-04-01
• 8 is the only release under active LTS
• 10 is an LTS candidate but won't actually be LTS until 2018-10-01

Therefore the next major change is that on 2018-10-01, 10 will be added to the list of "active" LTS.

Here is our internal list, used for Travis-only right now:

const policies = {
  lts: [6, 8],
  active: [8, 10],
  current: [10],
  lts_active: [8],
  lts_latest: [8],
};

I think this is how it would change:

const policies = {
  lts: [6, 8, 10],
  active: [8, 10, 11],
  current: [11],
  lts_active: [8, 10],
  lts_latest: [10],
};

current: whatever the highest release is. 10.9.0 right now, will be 11.x once it has started. there is only one current.

active: after start date and before maintenance date

lts: after LTS date and before end date

lts_active: after LTS date and before maintenance date

lts_latest: highest lts_active version

[rarkins]

So something to work out is how to "bump" ranges where the lower end is now unsupported. e.g. someone currently using >= 4.0.0 in engines. Similar concept to if a version is considered insecure. In such cases I think people want their ranges "bumped" but only to the minimum supported and/or secure version.

e.g. if you care about supported/LTS versions only then you would want to bump to >= 6.9.0. If you also care about secure, then you'd want it bumped to >= 6.14.3.

Note: I am not aware of any place where the Node.js project contains a semantic or even scrape-compatible list of minimum LTS versions or secure versions, so we would have to store these ourselves.

Another challenge if we do this is how to communicate it in PRs. Right now we don't really have a way to say "Version X is now LTS" or "Version Y is now in maintenance mode", etc. Similar for if we need to bump a range for security reasons.

[nevir]

@types/node is also interesting, because Y.Z versions are not kept in sync with node releases (e.g. @types/node 8.9.0 might be the best declarations for Node 8.12.0)

[rarkins]

Thanks @nevir. Indeed, @types/* version handling definitely seems like a challenge across the board. I would happily add improved support for types if I could only think of rules that work reliably for their versions.

[nevir]

For node, I think matching the major version is good enough; but that heuristic definitely doesn't work for all @types packages :(

[rarkins]

Link to PR discussion: #2079

[SpainTrain]

Until recently, we had observed the correct behavior of package.json -> engines and .circleci/config.yaml both having node version updated in the same PR. Recently, we have had these open in separate PRs. Is this intended and there is some config now to ensure they are in the same PR? If they are not in the same PR, we end up with failing CI, naturally.

Thanks!

Note: Please LMK if this belongs in https://github.com/renovatebot/config-help/issues

[rarkins]

We haven’t intentionally changed it. Can you reproduce in a public repo?

[rarkins]

In a new issue please

[viceice]

@rarkins I need a node datasource, which has the same behavior as the travis (getPackageUpdates) mananger.

This would also help to unify the node handling for all managers (at least for single replacement).

So i would start to create a new node datasource and refactor the travis.getPackageUpdates to use the new datasource.