Though it is undocumented it seems one can use Gatsby’s cache object to set and get json objects. Data is stored in the .cache/cache/{plugin-name}/ directory.

In your plugin gatsby-node.js in one of the many apis include cache as an argument; eg.

exports.onPostBuild = async function(
  { cache, store, graphql },
  { some, plugin, options} ) {
    const cacheKey = 'some-key-name';
    ...
    let obj = await cache.get(cacheKey);

    if (!obj) {
      obj = { created: Date.now() };
    }
    ...
    obj.modified = Date.now();

    await cache.set(cacheKey, obj);
  }

Issue: Import error when using component shadowing in gatsby-theme with gatsby 5.2.0

Description:

I am experiencing an import error when working with component shadowing in a gatsby-theme that uses gatsby 5.2.0. Every time I make a change in the codebase, I get the following error:

Attempted import error: ‘$virtual/async-requires’ does not contain a default export (imported as ‘asyncRequires’).

The only way to resolve this error is to run gatsby clean and then gatsby start again.

Steps to reproduce:

1. Create a gatsby-theme using gatsby 5.2.0
2. Use component shadowing in the theme
3. Make any change in the codebase
4. Observe the import error

Expected behavior:

I expect the code to recompile and update the site without any errors.

Actual behavior:

I am getting the import error described above every time I make a change in the codebase.

Environment:

• Gatsby version: 5.2.0
• Operating system: M1 MacOS

Additional context:

Has anyone else encountered this issue before? Is there a fix or workaround for this problem? I would really appreciate any help or guidance on how to resolve this issue. Thank you!

A potential cause of caching issues is mentioned here.

In short - if you create a node using createNode, without setting the parent field correctly, the node can be incorrectly garbage collected as part of the bootstrap process. Clearing the cache will correctly recreate the node.

This is a pretty systemic problem whenever adding a new image. Pretty much exclusively I have to rm -rf .cache/ and re-install. Sometimes I also just nuke the public/ folder. I know this is sort of already known, just figured that I’d share that I have had this experience.

Oops, unpinned this accidentally. Sorry!

(Perhaps GitHub should make repository actions more obvious 😛)

I have been having some issues with the cache as well, but on the other side. I have pretty bad internet for the time being, and having gatsby clear the cache every time I change a config is pretty frustrating. Rebuilds can take ~15 minutes. Wondering if we should cache different objects (images vs configs or built files) differently?

I think I ran into this issue and after much frustration I started this issue but ended up closing it after deleting the public folder and getting everything to work. I do believe this sounds a lot like what others are experiencing though.

My GraphQL query included a clause to another JSON file with an id property. Were they clashing somehow?

@edsu This is likely it. gatsby-transformer-json uses your id if you supply one but Node IDs must be universally unique as all nodes live in the same namespace — see https://www.gatsbyjs.com/docs/reference/config-files/actions/#createNode

I abstracted a lot of functions utilized inside my sourceNodes function into a separate file. Changes made in that file were not detected by cache busting, and so any time I changed the code in my abstracted file, I would have to clear the cache manually. Any way that Gatsby could detect changes in required files within gatsby-node.js would be advantageous to my use case.

We’ve run into an issue with contentful where, when we’ve added images via a rich-text, we’ve had to delete the .cache folder in order to query additional properties with GraphQL on the embedded asset.

For instance, we’ve added images, re-started the dev server, and were still unable to query image properties like

target {
   fields {
      file {
         url
      }
   }
}

deleting the .cache folder, solved this for us.

Please bear in mind that I am not 100% sure this was the cause of the issue forcing me to delete the .cache directory but it did fix the issue as soon as I did. I have a json file with an array of objects. I decided to give each object an identifier key. Gatsby does not like this key name, maybe it conflicts with an internal key name. I renamed the identifier to name but the related changes were not being built until I deleted the .cache directory.