If I聽add a gatsby plugin as gatsby-transformer-json and reload the server, nothing append (no new nodes into graphql schema)
The cache (.cache folder) has no idea of my modification, so no need to regenerate anything.
The idea is to add a sha1 of package.json and gatsby-config.js somewhere into .cache to check if something change in this criticals files. Finally, unvalidate the cache on any changes.
We should also hash the gatsby-node.js for each plugin as some plugins e.g. the site's own gatsby-node.js won't have a version number most likely so won't have any other way to know if something has changed...
I feel like perhaps we're not thinking about this correctly... need to do a rethink of this...
Ooo... figured it out. We just need to do the same thing for plugins as we're already doing for data sources and graphql queries. We need to track which plugins are modifying which data nodes so when a plugin is changed, we then make that plugin reprocess those same nodes.
What's really exciting about this is it could lead to hot-reloading of data transformers. So whenever you change a plugin, Gatsby reloads it and then takes all the nodes that the plugin has touched in the past and passes them through the plugin again. So hot-reloading of content, queries, and processing logic. 馃帀
Another issue with caching: sharp don't regenerate images if I change size or quality (I need to erase .cache and reload gatsby-dev)
Another issue with caching: sharp don't regenerate images if I change size or quality (I need to erase .cache and reload gatsby-dev)
This is a different issue potentially. Right now Sharp doesn't generate images after the initial bootstrap. So if you're trying to rewrite graphql queries while the server is running, new images won't be generated. And on re-starting, Gatsby will think that the query affecting Sharp has already been run (which it has) so won't run it again meaning images won't be generated then either.
Anyways, I'll fix that today actually as it's been on my TODO list for a long while now and really needs fixed.
Fixed by https://github.com/gatsbyjs/gatsby/pull/927 馃帀
Same problem when adding a field in the frontmatter of a markdown file (didn't know if I had to create another issue)
I can even add the field to my query and call it in my React component and no error is thrown. I just get 'undefined' so either my dom element don't show or I get the string 'undefined'... which is kind of funny but not really helpful. ^^'
If I manually delete the cache -> back to normal.
@MarcCoet what are the exact steps you took here to create this problem? Are you running the latest code?
Sorry. Completely overwhelmed these days. I am working on this project all day today.
I am having issues with markdown processing (e.g. project build locally but fail on netlify, ...). I'll try to get it to work again and see if the above mentioned problem still exists then.
Not the same as the one I mentioned above but still about clearing cache manually
.cache folder (-> Yaaay!)@KyleAMathews tell me if you are not interested in this kind of manual clear cache thing for the moment. If you are however I'll keep on posting them here unless you point me somewhere else.
Most helpful comment
We should also hash the
gatsby-node.jsfor each plugin as some plugins e.g. the site's owngatsby-node.jswon't have a version number most likely so won't have any other way to know if something has changed...I feel like perhaps we're not thinking about this correctly... need to do a rethink of this...
Ooo... figured it out. We just need to do the same thing for plugins as we're already doing for data sources and graphql queries. We need to track which plugins are modifying which data nodes so when a plugin is changed, we then make that plugin reprocess those same nodes.
What's really exciting about this is it could lead to hot-reloading of data transformers. So whenever you change a plugin, Gatsby reloads it and then takes all the nodes that the plugin has touched in the past and passes them through the plugin again. So hot-reloading of content, queries, and processing logic. 馃帀