chore: bump node min version to 10.13.0

[freiksenet]

Node 8 reached end of life in December of 2019. There were deprecation warnings about it in previous Gatsby versions. Less than 3% of Gatsby users are still using Node 8. Some libraries that Gatsby or Gatsby plugins depend on have dropped Node 8. This meant that we were locked into using an older version of packages and couldn’t apply the latest bugfixes (that was a case with, e.g., sharp or got). Some performance and memory improvements were only possible with newer versions of Node too.

Evaluating all those factors, we decided that it’s better to drop Node 8 support in a minor version, rather than wait further.

[wardpeet]

Can we explicitly set circleci to test 10.13 so we don't have regressions when upgrading packages.

[wardpeet]

Sorry mostly talking about

gatsby/.circleci/config.yml

Line 10 in d9c6415

default: "10"

[pvdz]

The changes lgtm. I think this PR is more about what's missing but I think we're looking good...

[wardpeet]

Do we need .yarn/releases/yarn-1.21.0.js in our repo? It's an extra 5mb

[freiksenet]

@wardpeet Yes if we want to make sure Yarn is of correct version.

[wardpeet]

why don't we install it in circleci instead?

[wardpeet]

LGTM! Added a few typo fixes and @herecydev also caught one.

[NickColley]

Heya folks (cc @freiksenet, @wardpeet),

We have a project that depends on on Gatsby version ^2.9.8 with Node.js version 8, which in turn depends on gatsby-cli ^2.6.11, since the caret (^) updates minor/patch versions it has resolved to version 2.12.18 which means it has broken our build.

Should have this bump been in a major version (3.0.0) for gatsby-cli? If so it would be helpful if you could publish some new versions to address it.

I will look into the possibility of having a locked version by modifying a package-lock, and of course upgrading the project. This project is something that we're maintaining without active feature development so you can imagine this is not trivial.

Just raising in case this is helpful, I may be mistaken, let me know if you'd like any more information.

[herecydev]

@NickColley See https://www.gatsbyjs.org/docs/upgrading-node-js/ for some further explanation. A lockfile (either yarn or npm) and constraining the version using a tilda would solve this for you, i.e. ~2.9.8

[freiksenet]

@NickColley Thanks for the heads up!

We are very sorry for this situation, we are always trying to not do changes like that during minor releases. Unfortunately we didn't have a proper major version release process, which forced us to do this kind of change because of Node deprecation. We are changing the process so that we have a regular major version release cadence and this will let us be more stable in between those releases.

I recommend locking the version in package-lock.json for now or upgrading Node - there shouldn't be any breaking changes except for node version between those versions of Gatsby.

[NickColley]

It would be really helpful if you could commit to your stance here:

Gatsby takes backwards compatibility seriously

• https://www.gatsbyjs.org/docs/upgrading-node-js/

As soon as you realize that you’ve broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it’s appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.

• https://semver.org/#what-do-i-do-if-i-accidentally-release-a-backwards-incompatible-change-as-a-minor-version

In the meantime I'll attempt to upgrade our applications dependencies as pinning the version in the package-lock is not working out. Thanks for the reply, good luck. 👍