Downgrading to older Gatsby version throws various errors

[josephmarkus]

Description

Describe the issue that you're seeing.I decided to upgrade a bunch of outdated gatsby dependencies (see a screenshot from the PR below). Then I discovered a bug (see #25522). I found that the problem was in a particular version of gatsby, so I thought if I simply roll it back to a version before the issue was introduced, it would work smoothly.

These are headline summaries of me trying to pin versions of gatsby with versions of gatsby-cli (it was pointed out in one of the issues that a version of gatsby-cli should be pinned):

gatsby@2.18.0 + gatsby-cli@2.8.12 - broken - Error: Reducers may not dispatch actions.

gatsby@2.18.25 - broken - activities of undefined error (yoga layout)
See - #23214

gatsby@2.19.0 + gatsby-cli@2.8.27 - broken - Error: Reducers may not dispatch actions.

gatsby@2.19.39 - broken - activities of undefined error (yoga layout)

gatsby@2.19.50 + gatsby-cli@2.10.13 - broken - Error: Reducers may not dispatch actions.

gatsby@2.20.24 - broken - Error: Reducers may not dispatch actions.

gatsby@2.20.26 + gatsby-cli@2.11.12 - broken - Error: Reducers may not dispatch actions.

gatsby@2.21.0 - broken

I tried to pin versions of gatsby-cli by adding the following to package.json:

"resolutions": {
    "**/gatsby-cli": "2.8.12",
}

What I came to realise is that EVERY gatsby dependency is prefixed with a caret, so even if I yarn add gatsby@2.19.0, all gatsby's own dependencies would be whatever is the latest version than that defined at the time of release, unless I specifically pin them through resolutions object (see above)

"@babel/code-frame": "^7.5.5"
"@babel/core": "^7.7.2"
"@babel/parser": "^7.7.3"
"@babel/polyfill": "^7.7.0"
"@babel/runtime": "^7.7.2"
"@babel/traverse": "^7.7.2"
"@gatsbyjs/relay-compiler": "2.0.0-printer-fix.4"
"@hapi/joi": "^15.1.1"
"@mikaelkristiansson/domready": "^1.0.9"
"@pieh/friendly-errors-webpack-plugin": "1.7.0-chalk-2"
"@reach/router": "^1.2.1"
"@typescript-eslint/eslint-plugin": "^2.7.0"
"@typescript-eslint/parser": "^2.7.0"
"address": "1.1.2"
"autoprefixer": "^9.7.1"
"axios": "^0.19.0"
"babel-core": "7.0.0-bridge.0"
"babel-eslint": "^10.0.3"
"babel-loader": "^8.0.6"
"babel-plugin-add-module-exports": "^0.3.3"
"babel-plugin-dynamic-import-node": "^2.3.0"
"babel-plugin-remove-graphql-queries": "^2.7.16"
"babel-preset-gatsby": "^0.2.22"
"better-opn": "1.0.0"
"better-queue": "^3.8.10"
"bluebird": "^3.7.1"
"browserslist": "3.2.8"
"cache-manager": "^2.10.1"
"cache-manager-fs-hash": "^0.0.7"
"chalk": "^2.4.2"
"chokidar": "3.3.0"
"common-tags": "^1.8.0"
"compression": "^1.7.4"
"convert-hrtime": "^3.0.0"
...

What I would like to do is be able to add a version of gatsby at the time it was released. Currently, I have all sorts of incompatibility issues that break my builds, which is due to all gatsby's own dependencies being newer than gatsby itself.

I spent hours on this and got nowhere. In the end I rolled back my gatsby version to what it was before: ~2.13.x

Steps to reproduce

1. Pick a version that you'd like to rollback to from here - https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/CHANGELOG.md
2. Click on the version, then click on commit called chore(release): Publish
3. Find packages/gatsby/package.json in files changed and keep this tab open for reference
4. In your terminal downgrade gatsby to a different version like so yarn upgrade gatsby@x.xx.xx where x represents your chosen gatsby version
5. Check your yarn.lock under gatsby@x.xx.xx and compare installed packaged versions to those you see in the changelog

Expected result

I would expect to see gatsby dependency tree in my yarn.lock to match dependency versions outlined in package.json when a given version was released

Actual result

Gatsby dependency versions do not match, leading to various errors as it's unclear which package depends on what.

Environment

System:
    OS: macOS Mojave 10.14.6
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.18.0 - ~/.nvm/versions/node/v12.18.0/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v12.18.0/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 83.0.4103.116
    Safari: 13.1.1
  npmPackages:
    gatsby: ~2.13.x => 2.13.83
    gatsby-background-image: ^1.1.1 => 1.1.1
    gatsby-image: ~2.4.12 => 2.4.12
    gatsby-plugin-catch-links: ~2.3.10 => 2.3.10
    gatsby-plugin-emotion: ~2.0.5 => 2.0.7
    gatsby-plugin-favicon: ~3.1.5 => 3.1.6
    gatsby-plugin-google-gtag: ~2.1.9 => 2.1.9
    gatsby-plugin-manifest: ~2.4.17 => 2.4.17
    gatsby-plugin-mdx: ^1.2.22 => 1.2.22
    gatsby-plugin-postcss: ~2.3.9 => 2.3.9
    gatsby-plugin-react-helmet: ~3.3.9 => 3.3.9
    gatsby-plugin-remove-generator: ^1.0.5 => 1.0.5
    gatsby-plugin-remove-serviceworker: ^1.0.0 => 1.0.0
    gatsby-plugin-robots-txt: ~1.5.1 => 1.5.1
    gatsby-plugin-root-import: ~2.0.5 => 2.0.5
    gatsby-plugin-sharp: ~2.6.18 => 2.6.18
    gatsby-plugin-sitemap: ~2.4.10 => 2.4.10
    gatsby-remark-autolink-headers: ^2.3.10 => 2.3.10
    gatsby-remark-copy-linked-files: ^2.3.10 => 2.3.10
    gatsby-remark-external-links: ~0.0.4 => 0.0.4
    gatsby-remark-images: ~3.3.17 => 3.3.17
    gatsby-remark-relative-images: ^0.2.2 => 0.2.3
    gatsby-remark-responsive-iframe: ~2.4.10 => 2.4.10
    gatsby-source-filesystem: ~2.3.18 => 2.3.18
    gatsby-source-youtube-v2: ^1.0.1 => 1.0.1
    gatsby-transformer-remark: ^2.8.23 => 2.8.23
    gatsby-transformer-sharp: ~2.5.10 => 2.5.10
  npmGlobalPackages:
    gatsby-cli: 2.12.59

[pieh]

#25478 is the issue that cause this - so you should be able to just pin xstate dep as I mentioned in #25478 (comment)

[pieh]

Talking about using caret version selectors - it's never black and white. There is just no good solution to do this. Yes pinning deps could potentially prevent this, but it's not guaranteed as most of dependencies that gatsby use have their own deps using carret version selectors. This is also default behaviour for npm and yarn to use them when adding new package via npm install X / yarn add X

[josephmarkus]

Thanks for the update @pieh. I didn't even think of other dependencies having their own dependencies. It's like a never ending tree. Perhaps caret in dependency management just isn't a great default.

[joyfulelement]

Have been battling with the similar issue where gatsby develop fails, and either upgrading/downloading gatsby dependency helps, because it would simply breaks the local environment.

As @josephmarkus pointed out, for example, because the way caret ^ is used for gatsby-cli which is the direct dependency of gatsby:

in package-lock.json
---
"gatsby": {
  "version": "2.20.24",
  ...
  "requires": {
    ...
    "gatsby-cli": "^2.11.10", <--- installs v2.12.60 on 7/10
    ...
    "xstate": "^4.8.0", <--- installs 4.11.0 on 7/10
    ...
  },
  ...
}

you would end up using a different/newer version of gatsby-cli or xstate every time you run npm install without changing package.json. So depending on the time you run npm install, you may end up with a different line-up of dependencies installed on the local environment Vs build environment...etc. Any new incompatibility issue is not noticeable for anyone using gatsby develop locally that is still base on the older version of gatsby-cli from the previous npm install run.

What makes the situation more challenging is npm itself doesn't come with the native support for resolution feature like yarn to pin the version of transitive dependencies. So if you've unknowingly run the npm install in a bad time, you lose the working version of the dependency line-up forever. So npm becomes useless without a workaround in this situation (npm install --save-exact is different than yarn resolution as it adds the dependency to the project's package.json).

Been falling back to use yarn + resolution at the moment, but still haven't reach the exact line up of gatsby dependencies along with its transitive dependencies to get gatsby develop working again.

I understanding from @pieh 's comment that the use of caret ^ has been the default behaviour of package managers, but I am curious that if we could at least make all the top-level dependencies that gastby directly depends upon without caret ^, i.e. locking down the version of top level dependencies, it would help us narrow down the issue with relatively less dependencies to track down when troubleshooting. Because as of today, EVERY top level dependencies are moving targets plus any transitive dependencies they depends upon.

[josephmarkus]

It's always a relief to hear that someone else shares the same experience, even if it isn't a pleasant one.

It would be great to be able to rollback to any package at a moment in time, rather than feel like buying a cat in a bag where at the time a package was released it worked for 98% of users with setup X and now it may not work at all. It's almost as if versioning fails on its primary purpose.

If I pick a package version that throws me errors I also have no way to tell which, in this case, gatsby's own dependency is failing. It just gives you a generic message and off you go to find it on Google, if you are lucky. I spent way too many hours on this and it was very frustrating to try and get something to work. It sometimes feels like a punishment trying to update dependencies - you had something that was working, but no more. The only safe rollback is git reset --hard origin/master -- yarn.lock and yarn install.

[ngbrown]

The caret version operator only works as well as the adherence to semver standards of not changing the public API for a given major version. Right now, Gatsby is bringing in a lot of dependencies without maintaining stable interfaces between them.

I think exact pinning should be used.

Even patch selectors ~ isn't enough if the patch number is incremented just because it's the next build, not a compatible patch.

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions]

Hey again!

It’s been 60 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to comment on this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜