Problems running through the public quick-start project exercise: Gatsy blog images are not displaying?

@markkaylor

Thank you, amigo. That resolved the build failure. This looks super-cool!

Spot-on call! I’ll attach my session log below.

And… wow. What a call on your part! What gave you the intuition on that? As a developer with no experience in Strapi + , I was lost, simply because I am so new to the entire ecosystem – so I had no idea where to begin.

I was resigning myself to try to cobble together a standalone Gatsby instance (using some other tutorials). But I was dreading that process, because other demos weren’t specifically tooled oto use this specific Strapi schema. In other words, what I really wanted to do was show the potential of Strapi (to fellow co-founders) without having to spend the time & learning curve working up a useful practical demo. You got me back on track. Thanks.

So – an important follow-up Q:

I believe the quick start demo process I used pulled everything down from your repo, and did all of its (most impressive) magicks from there. Does this mean that this potential build environment problem (on any given localhost) should be remedied by a code change in your repo to reflect your idea to enforce the version requirement for eslint?

In other words, In my previous attempt to troubleshoot the problem, I DID upgrade my base version of node.js (from 12 to 14). Historically, I’ve been using that to build (Ionic + Angular + Loopback) stacks, and simply didn’t give it a lot of thought before I charged off into the build cycle for this product evaluation. So that lameness was on me.

But it turned out that me policing my lameness did not solve the problem, and yours did.

In other words, should the versioning problem with eslint be corrected by a PR/merge into your repo, or is it better to try to enforce on the builder’s end?

Or perhaps should the build process even error out as soon as it realized my version of node.js was so far out of date.

My GitOps kung-fu is not at all sufficient to know how to de-risk the build process with version enforcement. But it seems to me that anything that derails the flagship “build this awesome demo” process should be de-risked as much as practically possible.

And it IS, by the way, an awesome demo. I am truly excited by the possibilities of Strapi.

Thanks again, amigo.

Session log attached below…