amphtml: Discussion to avoid node version incompatibility with LTSs

One year later, we’ve run into similar problems once again, due to node’s latest active LTS going from 10 to 12. The latest discussion on this topic can be found at #25209. (Bumping this old issue to link the two.)

Update: According to https://github.com/nodejs/Release, node 8 has entered Maintenance LTS status. The current active LTS is node 10.

I’ll send out a PR.

Thanks for starting this discussion.

To recap, The 10.0 LTS release broke us because we pinned our project’s package.json to the latest major LTS version (^8.0.0). This was okay when there was just one active LTS, although it still needed us to manually update the currently allowed version.

To fix this, the plan (after discussing with others) is to enable node version updates from Renovate using "supportPolicy": ["lts_active"] (https://renovatebot.com/docs/node/). This will allow us to use any one of the active LTS versions of node for local development, while using the latest active LTS for testing on Travis.

Edit: We’d also need to revert the version specified in .travis.yml to lts/*. This is being done in # #19234

I was suggesting pinning to a major version. eg ^8.0 to ^10.0 that should keep us up to date with bug fixes bug avid major version breakage.

Another approach would be to let greenkeeper do it on the basis that if it tries to update no in a way that breaks the test will catch it and it won’t get merged.

The issue with pinning to an exact version is delayed upgrades via manual enforcement. Although infrequent (~ once a year), the delay in upgrading can be removed entirely by using lts/*.

Downsides:

1. Version changes automatically, without notice, for all developers.
2. Uncertainty regarding stability of lts/*, since codebase isn’t tested before the lts release is required for all developers. (note: this is an issue needing resolution independently)

Upsides:

1. No manual effort to move Node versions
2. Can use the latest V8 features (and Node APIs) with confidence to make our build system code more readable, testable, and performant.

There is definitely a tradeoff. Supporting multiple versions means we need to ensure (via travis) that each commit works against the supported versions. When debugging an issue it will be important to know which versions are impacted. Developers working on the AMP codebase will likely need to use nvm or similar to test changes on multiple versions of Node (especially if leveraging newer APIs).

As code is changing, we should have a strong preference around the usage of Node features if we support multiple versions of Node. Should all build code be transpiled to ensure it runs against the oldest supported version?

Because of these factors, I’d ask we support a single Node version going forward, and only one at a time. “lts/*” meets this criteria.

But abandoning v8 just because v10 became the active LTS doesn’t make good sense. We’re just cutting off potential users.

Let’s see if any of the AMP design principles might assist in an answer.

User Experience > Developer Experience > Ease of Implementation.

This issue only impacts the ease of implementation, since developers of author pages shouldn’t need to run the repository to test their documents. As a result, its by far the lowest priority for informing a design decision.

Don’t design for a hypothetical faster future browser.

No impact.

Don’t break the web.

Potentially supporting only a single node version reduces the time for a Travis build to complete, but they are run mostly in parallel (so the impact isn’t that significant). If the version of AMP that is deployed is broken, pushing a fix could be slower. However, we also would likely rollback before pushing a fix – likely no impact.

Solve problems on the right layer.

No impact.

Only do things if they can be made fast.

No significant impact, newer versions of Node incorporate later versions of V8 which should improve overall build performance. However, the delta is likely low enough to be immaterial (metrics would help inform).

Prioritise things that improve the user experience – but compromise when needed.

No impact.

No “nicelists” or “allowed lists”.

No impact since this relates to allowlists for special treatment of domains.