Gatsby: Depending on the Gatsby version, the Netlify CLI UI breaks (long standing issue)

[tr1s]

Description

I've been having this UI issue for so long now, I posted the issue in Netlify's CLI github issues list as well. Please close if this feels unrelated to Gatsby, and is solely Netlify's problem to fix.

Issue: The Netlify CLI UI get's cut off by an "In Progress" bar that just sits there even though it's completed, cutting off the green "Server now ready on localhost:8888" section.

This issue doesn't happen when running the gatsby develop command, but does happen when running netlify dev, which in turn runs gatsby develop. I'm posting here in case anyone here might have some insights into the UI issue based on the two versions of Gatsby I outline below.

I decided to get to the bottom of it and figure out when this this issue starts... It doesn't happen on [email protected], but it does happen on [email protected] and later. But [email protected] is the very specific moment things break.

---

Here's a screenshot on [email protected], running netlify dev when things look normal:

Here's a screenshot on [email protected], running netlify dev when things look broken:

---

Environment

  System:
    OS: macOS 10.15.3
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 13.6.0 - ~/.nvm/versions/node/v13.6.0/bin/node
    npm: 6.13.4 - ~/.nvm/versions/node/v13.6.0/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 79.0.3945.130
    Safari: 13.0.5
  npmPackages:
    gatsby: ^2.16.0 => 2.16.0
    gatsby-plugin-catch-links: ^2.1.25 => 2.1.25
    gatsby-plugin-manifest: ^2.2.41 => 2.2.41
    gatsby-plugin-offline: ^3.0.34 => 3.0.34
    gatsby-plugin-react-helmet: ^3.1.22 => 3.1.22
    gatsby-plugin-sass: ^2.1.28 => 2.1.28
    gatsby-plugin-sharp: ^2.4.5 => 2.4.5
    gatsby-remark-images: ^3.1.44 => 3.1.44
    gatsby-remark-relative-images: ^0.2.3 => 0.2.3
    gatsby-source-contentful: ^2.1.85 => 2.1.85
    gatsby-source-filesystem: ^2.1.48 => 2.1.48
    gatsby-transformer-remark: ^2.6.50 => 2.6.50
    gatsby-transformer-sharp: ^2.3.14 => 2.3.14
  npmGlobalPackages:
    gatsby-cli: 2.8.27

Gatsby CLI version: 2.8.27
Gatsby version: 2.16.0
  Note: this is the Gatsby version for the site at: /Users/tris/Sites/tris/tris-gatsby

netlify-cli/2.31.0 darwin-x64 node-v13.6.0

[jlengstorf]

I posted this on https://github.com/netlify/cli/issues/698 as well, but just to surface this in both places:

this is happening on the repo I'm using for my Frontend Masters "Introduction to the JAMstack" course, which is scheduled to be released soon

if we could get this fixed before that goes live, that would probably help us avoid a lot of confusion

[erquhart]

A bit of research:

• this bug of Gatsby cli eating previous external logs was introduced in https://github.com/gatsbyjs/gatsby/pull/14973 (cc/ @pieh)
• it _might_ be due to this component, not positive
• is definitely related to ink, either the library itself or Gatsby's implementation of it
• may also be related to #19314
• setting GATSBY_LOGGER to yurnalist, as suggested in #19314 by @jlengstorf, is an effective workaround (not a solution, though)

[vladar]

May be also related: #19658

[github-actions[bot]]

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! 💪💜

[erquhart]

Not stale

_{Sent with GitHawk}

[pieh]

https://github.com/netlify/cli/blob/master/src/utils/command.js#L99 well here's netlify CLI trying to output directly to stdout, which ink supposed to have sole ownership of. This will make ink try to fight it.

It's not obvious how to solve this because to my understanding gatsby is spawned in separate process that inherit same stdio as netlify dev process?

[pieh]

In general ink was introduced because of issues when multiple "interactive" elements would fight for control over stdout which would result in flashing progress bars - something like this:

This is similar case, just here is something in completely different process which can't be reconciled (netlify CLI tries to append to stdout, but because this is "interactive" part of gatsby output - where we have spinners etc - parts of it will be cleared)

[pieh]

While I don't suggest to make this change in netlify CL master, as experiment, I I do wonder if changing https://github.com/netlify/cli/blob/master/src/utils/command.js#L99 to stderr from stdout would result in output not being cut 🤔

Other idea (more involved one) is to investigate ink internals and possibly make improvements there to prevent issues like that

[pieh]

Here's issue in ink about this https://github.com/vadimdemedes/ink/issues/162