This demo repo is a modified clone of the gatsby-starter-blog
.
"Article"-data is stored under ./src/data/articles.json
.
They get picked up by gatsby-source-filesystem
and transformed into nodes by gatsby-transformer-json
.
Then in gatsby-node.js
all articles get mapped and re-transformed into BlogArticle
-nodes using the sourceNodes
API.
While doing this, the referenced images get pulled via createRemoteFileNode
and they themselves get referenced to the BlogArticle
-node, by mapping all image nodes that are created this way.
const articleNode = await createNode({ article_images_source: images, article_images: all_article_image_nodes?.map(({ id }) => id), ... })
Finally, they all get linked in createSchemaCustomization
.
Like this:
type BlogArticle implements Node { article_images: [File] @link, thumbnail: File @link }
The first build (and all consecutive build w/out changes) will run just fine, all articles and images will show up. If you then however make a change to one of the images
-arrays inside the articles.json
file, all image links will break and the build will crash. I just cut one of the referenced images from the array and paste the whole object into the blog-article.js
and comment it out, so I can alternate between the two version relatively hassle free...
DON'T paste it into the gatsby-node.js-file though, since this will invalidate the cache and keep the build running!
gatsby develop
will still run, giving a hint in whats going on:
Notice how all article_images
-nodes have an ID and also each one has a childImageSharp
-node with an own ID.
Notice how all article_images
-nodes have an ID, but childImageSharp
is always null
.
One more very interesting fact: all thumbnail
nodes are still there and all still have their childImageSharp
referenced correctly.
In gatsby-node
you can see some commented code, that sort of manually gets cached image nodes and links those to the BlogArticle
-nodes. You can see this working when you un-comment these lines (the code ones of course, not the "actual" comments 😉) and then build -> make said change to the articles.json
-> DONT delete the cache or make a change to one of the API files -> rebuild w/ cache -> profit.
The flag PRESERVE_FILE_DOWNLOAD_CACHE
is active, because in our production project, we're talking thousands of remotely stored images. Would be a shame to lose the cache every time someone adds a mere comment inside gatsby-node.js
I did this re-transforming of already created json nodes, because in our production project, articles are stored in a Cloud-Storage and fetched when building, thus making this necessary for reproducing the error.