gatsby develop build become stuck with node v12.x on Mac?

[joyfulelement]

Description

After some upgrade of the local gatsby development environment with the latest dependencies and Node version (from v10.x => v12.x), I noticed gatsby develop build started to hang at the end without completing the build for the development environment with webpack server serving the content for local testing.

Spend over a week by downgrading/upgrading the dependencies and hit several issues along the way e.g. #25607 and finally ended up finding its the Node version 12.x the local gatsby build is not compatible with.

I am not sure if anyone else experienced the same issue when using Node version 12.x today, but below I have compiled the table with permutation of different gatsby dependencies I tested over the week of trial and error and hopefully help the next person who may bump into the same issue.

Steps to reproduce

Try with one of the following Node versions:

• Node v12.14.1
• Node v12.18.0

Run with the gatsby dependencies below by running gatsby develop.
Results are recorded in the table below.

Note that due to the way that gatsby's dependency line up are defined, they are not locked as mentioned on #25607 (comment), downgrading gatsby dependency with specific build of e.g. gatsby-cli require using yarn's resolution feature.

e.g.

"resolutions": {
    "gatsby/gatsby-cli": "2.7.7",
    "gatsby/webpack-dev-server": "3.10.3"
  },

#	gatsby	gatsby-cli (pined with yarn resolution)	Other dependency (pined with yarn resolution)	gatsby develop run Result
1	2.24.2	2.12.60	xtate 4.11.0	stuck after success write out requires - 0.005s
2	2.23.18	2.12.57		gets stuck after success write out requires - 0.014s
3	2.23.3	2.12.60		stuck at [============================] 1331.030 s 44517/44518 100% Generating image thumbnails Run again will get Error: listen EADDRINUSE: address already in use 0.0.0.0:5050 Force quit the hanged node process and run again and stuck at success run page queries - 0.052s - 3/3 57.57/s
4	2.23.3	2.12.45	xtate 4.10.0	use to work with Node v10.x stuck after success run page queries - 105.787s - 156/156 1.47/s
5	2.22.0	2.12.60		get stuck after success run queries - 0.065s - 3/3 45.94/s
6	2.21.36	2.12.60		UNHANDLED REJECTION Reducers may not dispatch actions.
7	2.20.26	2.12.55	xtate 4.10.0	gets stuck after success run queries - 0.064s - 3/3 46.81/s port number gets used
8	2.20.24	2.12.48	xtate 4.10.0	Initially hit Error: Reducers may not dispatch actions. fix with pin xstate 4.10.0 (only work with v10.21.0) stuck after success run queries - 132.094s - 157/157 1.19/s
9	2.19.0			yoga-layout activity issue (fixed in #23214 with gatsby 2.20.24)
10	2.18.0			yoga-layout activity issue (fixed in #23214 with gatsby 2.20.24)
11	2.17.0			yoga-layout activity issue (fixed in #23214 with gatsby 2.20.24)
12	2.16.0			yoga-layout activity issue (fixed in #23214 with gatsby 2.20.24)
13	2.13.83	2.8.12	webpack-dev-server: 3.10.3	stuck at ⠙ start webpack server ✨ Done in 1983.95s.
14	2.12.48			Stuck
15	2.12.1	2.12.60		stuck at success run page queries - 56.324s - 156/156 2.77 queries/second
16	2.12.1	2.7.7	webpack-dev-server: 3.10.3	stuck at ⠼ run page queries — 156/156 2.47 queries/second
17	2.7.1	2.6.2	gatsby-transformer-remark: 2.3.12 gatsby-transformer-sharp: 2.1.19	(sharp:39770): GLib-GObject-WARNING **: 23:21:35.325: cannot register existing type ‘VipsObject’ (sharp:39770): GLib-CRITICAL **: 23:21:35.327: g_once_init_leave: assertion ‘result != 0’ failed (sharp:39770): GLib-GObject-CRITICAL **: 23:21:35.327: g_type_register_static: assertion ‘parent_type > 0’ failed (sharp:39770): GLib-CRITICAL **: 23:21:35.327: g_once_init_leave: assertion ‘result != 0’ failed

Expected result

The gatsby develop build should succeed without getting stuck indefinitely.

Actual result

The gatsby develop build hanged indefinitely.
gatsby develop build does not produce the following:

You can now view xxxxxx in the browser.
⠀
  Local:            http://localhost:5050/
⠀
View GraphiQL, an in-browser IDE, to explore your site's data and schema
⠀
  Local:            http://localhost:5050/___graphql
⠀
Note that the development build is not optimized.
To create a production build, use gatsby build

Some times, Node process does bind against the port but accessing it via browser does not return the HTML.
After terminating it with ctrl+c from CLI, you would have to manually terminate the Node processes from Activity Monitor (Mac)

Environment

gatsby info

 System:
  OS: macOS Mojave 10.14.6
  CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
  Shell: 3.2.57 - /bin/bash
 Binaries:
  Node: 12.18.0 - /var/folders/7l/lq881yln37nbsd27r7n_yhkwyffx10/T/yarn--1594513569033-0.15903330997510245/node
  Yarn: 1.17.3 - /var/folders/7l/lq881yln37nbsd27r7n_yhkwyffx10/T/yarn--1594513569033-0.15903330997510245/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
  Edge: 83.0.478.61
  Firefox: 79.0
  Safari: 13.1.1
 npmPackages:
  gatsby: 2.24.2 => 2.24.2
  gatsby-image: 2.4.7 => 2.4.7
  gatsby-plugin-algolia: 0.5.0 => 0.5.0
  gatsby-plugin-canonical-urls: ^2.0.13 => 2.3.10
  gatsby-plugin-catch-links: ^2.0.2 => 2.3.11
  gatsby-plugin-dark-mode: 1.1.0 => 1.1.0
  gatsby-plugin-feed: 2.3.25 => 2.3.25
  gatsby-plugin-google-analytics: 2.3.8 => 2.3.8
  gatsby-plugin-google-tagmanager: 2.3.9 => 2.3.9
  gatsby-plugin-layout: ^1.0.2 => 1.3.10
  gatsby-plugin-manifest: 2.4.11 => 2.4.11
  gatsby-plugin-netlify: ^2.0.0 => 2.3.11
  gatsby-plugin-offline: 3.2.9 => 3.2.9
  gatsby-plugin-react-helmet: ^3.0.0 => 3.3.10
  gatsby-plugin-react-svg: ^2.0.0 => 2.1.2
  gatsby-plugin-robots-txt: ^1.5.0 => 1.5.1
  gatsby-plugin-s3: 0.3.3 => 0.3.3
  gatsby-plugin-sharp: 2.6.11 => 2.6.11
  gatsby-plugin-sitemap: 2.2.19 => 2.2.19
  gatsby-plugin-styled-jsx: ^3.0.1 => 3.3.11
  gatsby-plugin-styled-jsx-postcss: ^2.0.2 => 2.0.2
  gatsby-remark-autolink-headers: ^2.1.25 => 2.3.11
  gatsby-remark-copy-linked-files: ^2.0.5 => 2.3.11
  gatsby-remark-embed-video: ^2.0.1 => 2.0.1
  gatsby-remark-emoji: 0.0.3 => 0.0.3
  gatsby-remark-external-links: 0.0.4 => 0.0.4
  gatsby-remark-images: 3.3.10 => 3.3.10
  gatsby-remark-prismjs: ^3.0.0 => 3.5.10
  gatsby-remark-responsive-iframe: ^2.0.5 => 2.4.11
  gatsby-remark-smartypants: ^2.0.5 => 2.3.10
  gatsby-remark-table-of-contents: 0.0.9 => 0.0.9
  gatsby-source-filesystem: 2.3.11 => 2.3.11
  gatsby-transformer-remark: 2.8.16 => 2.8.16
  gatsby-transformer-sharp: 2.5.5 => 2.5.5

Workaround

Fall back the Node version from 12.x ==> v10.x or v10.21.0

Result

The build with gatsby develop will complete.
Tested with the gatsby dependency:

• gatsby: 2.24.2
• gatsby-cli: 2.12.60

[joyfulelement]

The issue seems to be happening also on Gatsby Cloud

I tried building my markdown based gatsby website with Gatsby Cloud which uses the following versions of Node and Gatsby for its build env:

Node version v12.18.3
Gatsby CLI version: 2.12.80 
Gatsby version: 2.24.27

The entire build got timed out after 2 h 49m 59s.

With the raw log hanged at:

19:58:12 PM: success run page queries - 466.716s - 171/171 0.37/s
21:03:51 PM: [styled-jsx] Loading plugin from path: styled-jsx-plugin-postcss

Again, no issue with Node v10.

Not sure if anyone else has encountered the same experience on Gatsby Cloud.

[danyim]

Also ran into this with Node 12:

gatsby info

  System:
    OS: macOS 10.15.6
    CPU: (8) x64 Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.18.4 - ~/.nvm/versions/node/v12.18.4/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.4/bin/npm
  Languages:
    Python: 2.7.17 - /usr/local/bin/python
  Browsers:
    Chrome: 85.0.4183.121
    Firefox: 72.0.2
  npmPackages:
    gatsby: ^2.24.73 => 2.24.73
    gatsby-image: ^2.4.21 => 2.4.21
    gatsby-plugin-manifest: ^2.4.34 => 2.4.34
    gatsby-plugin-offline: ^3.2.31 => 3.2.31
    gatsby-plugin-postcss: ^3.0.1 => 3.0.1
    gatsby-plugin-react-helmet: ^3.3.14 => 3.3.14
    gatsby-plugin-sharp: ^2.6.40 => 2.6.40
    gatsby-plugin-sitemap: ^2.4.15 => 2.4.15
    gatsby-plugin-styled-components: ^3.3.14 => 3.3.14
    gatsby-plugin-typescript: ^2.4.21 => 2.4.21
    gatsby-plugin-web-font-loader: ^1.0.4 => 1.0.4
    gatsby-source-filesystem: ^2.3.34 => 2.3.34
    gatsby-source-wordpress: ^3.3.38 => 3.3.38
    gatsby-transformer-sharp: ^2.5.17 => 2.5.17

[kohane27]

Update: Indeed it was the problem with node version. I really had to be on node 10.22.1 in order to get unstuck.
I have to use the Node.js version manager for Windows to deal with this. Not sure if the following has anything to do with successfully avoiding gatsby develop failure.

==============================================================

tl;dr: I was stuck on gatsby develop but I'm on Windows 10 so I'm sure how relevant this comment is. node version wasn't the problem. Visual C++ Build Tools was the root cause of gatsby develop failure.

I've tested on both node 10.16.0 and 14.14.0: they both works after Visual C++ Build Tools is properly installed.

The problem for me was Visual C++ Build Tools. I followed the Gatsby on Windows guide:

The recommended way to setup your build environment on Windows is to install the windows-build-tools package by running npm install --global windows-build-tools --vs2015

It still didn't work for me. So I continued the If npm install still fails guide:

download the Visual Studio Community 2015 Package (also available from this direct download link) and install only the part of the package that interests us : Programming languages > Visual C++ > Common tools for Visual Studio 2015.

After downloading the 6GB Common tools for Visual Studio 2015, running gatsby develop finally works.

[pieh]

The original issue is likely duplicate of #27184 (comment) - TL/DR gatsby-plugin-styled-jsx-postcss (or rather underlying dependencies) get stuck in Node 12

[LekoArts]

Closing this as stale since in the meantime Gatsby v4 and updated related packages were released. Please try with the latest versions and if you still see this problem open a new bug report (it must include a minimal reproduction).