Gatsby: Update Gatsby to support Node 8 and above

[m-allanson]

Summary

Node 6 has reached its official end-of-life date as of 30th April 2019.

Today Gatsby _mostly_ supports Node 6. However as some of Gatsby's dependencies have upgraded, they've dropped Node 6 support. This means that e.g. gatsby new won't work when running Node 6, but an existing site will continue to build fine (for now).

Increasingly we are having to make decisions about dependencies that have (rightly) stopped supporting Node 6.

We should create a policy on how Gatsby intends to handle supporting Node versions, then implement that policy for Gatsby's Node 6 support.

Related reading:

• Gatsby Node 8 RFC
• Node's releases doc

Proposals

Gatsby should support any Node version who's status is _Current Release_, _Active LTS_, or _Maintenance LTS_. I think that's not too controversial.

What do we do once a supported version reaches _End of Life_ status?

1. Stop actively supporting that version of Node?

   • This means it may work, but the Gatsby team will not run tests or fix issues related to that version of Node. In addition, Gatsby dependencies can be upgraded to versions that may drop support for that version of Node.
   • Essentially - you can try and run Gatsby with this version of Node, but you're on your own.

2. Explicitly drop support for that version of Node

   • Release minor versions of Gatsby and official plugins that drop support for that version of Node. This would involve work like updating babel-preset-gatsby to target only newer Node versions, resulting in less code being shipped.
   • Gatsby definitely won't work if you try and use this version of Node.

3. Release a major version of Gatsby and related plugins that drops support for that version?

   • Releasing major versions is a huge amount of churn for a change that most people won't notice. (It's worth noting here that Gatsby doesn't officially follow semver's versioning conventions)

4. Something else?

Motivation

Time passes, Node versions increment and fade away, Gatsby must adapt.

Edit: updated to show we've gone with option 2. See comments for to-dos.

[m-allanson]

Gatsby's telemetry data indicates that around 0.75% of people are currently using Node 6 with their Gatsby project.

[m-allanson]

We could do something like this https://github.com/verdaccio/verdaccio/pull/968/files

[DSchau]

@m-allanson I think that's a worthwhile thing to do. We do that similarly in gatsby-cli, but it's not quite as robust or nice as verdaccio's solution. https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-cli/src/index.js#L18

I also think engines would work pretty well here? At least, in theory 🤞

[m-allanson]

problems problems:

• https://github.com/gatsbyjs/gatsby/pull/14694#issuecomment-500619211
• https://github.com/gatsbyjs/gatsby/pull/14657#issuecomment-500267293

[KyleAMathews]

We'd want very good docs for upgrading people's node version — e.g. we detect what OS they're on, how they installed it (homebrew, download, etc.) etc. Otherwise we'll just lose a lot of people.

[m-allanson]

Our Node 6 support is starting to block other PRs. We're going to go with option two - release a minor version of Gatsby that checks for the version of Node you’re running and exits with an error message if you’re using Node 6.

Something like - “Your version of Node 6.x.x has reached end of life, please update to Node 8 or downgrade to gatsby 2.x.x to continue. See gatsby.dev/node-js-versions”)

PR #14785 adds a first set of documentation on when Gatsby will drop support for a given Node version, and how to upgrade from Node 6.

We'd want very good docs for upgrading people's node version

The new upgrade guide covers upgrading using homebrew (as recommended in tutorial part 0), tools like nvm and n and downloading the installer from nodejs.org.

We could potentially update the docs with instructions on how to use babel-node if we're seeing further problems from people upgrading.

[sidharthachatterjee]

Next steps:

• [x] Add a nice error message saying that we've dropped support if run on Node < 8 with a CTA to http://gatsby.dev/upgrading-node-js
• [x] Remove Node 6 from unit testing config
• [ ] Publish minor version with these changes

Follow ups (for a new issue?):

• [x] Tweak Babel preset to target Node 8
• [ ] Upgrade all dependencies that have been blocked by this

Edit: @m-allanson edited this todo list ☝️

[DSchau]

In thinking more about this--our main reservation in a major release is primarily in (pre-maturely) releasing Gatsby v3.0.0 and not being able to group more meaningful breaking changes (e.g. webpack, API changes, etc.).

This is a fair reason. However, to make strides towards reducing even less churn, I propose the following:

1. Minor release of gatsby (2.10.0)
2. Major release of all _other_ packages (e.g. gatsby-plugin-emotion 4.x.x -> 5.0.0)
3. Adding engines to all packages (besides gatsby-cli, which will still "support" Node 6 and throw an error on launch) to indicate support for Node >=8.0.0

Doing this will let people pin Gatsby to a certain version (prior to 2.1.0) and then keep their _current_ versions of packages within the version range that supported Node 6, which again mitigates churn.

Thoughts?

[KyleAMathews]

I'd say no. Major releases are bad because very few update. We don't want to harm everyone on v8+ by opting them out of improvements. Also the logic is inconsistent. People on v6 are just as broken with major releases for plugins. If they really want to stay put, they can pin everything.