Image untouched transformer plugin #1513
Conversation
|
Deploy preview failed. Built with commit 8a1c8c8 https://app.netlify.com/sites/using-styled-components/deploys/596982d36f4c502fa73c3bfc |
|
Deploy preview ready! Built with commit 8a1c8c8 |
|
Deploy preview ready! Built with commit 8a1c8c8 |
|
Deploy preview ready! Built with commit 8a1c8c8 |
|
So you want to be able to query for images but not process them in any way? Could you just add this to ability Also curious why you're seeing so much overhead from using Sharp? Gatsbygram creates 1000s of thumbnails and finishes within a couple of minutes on the first run and then since images aren't reprocessed on subsequent runs, adds no overhead for incremental builds. Also, as an FYI, but Node type names should be tied to the name of the plugin that creates them. As this is, it couldn't be installed alongside gatsby-transformer-remark as the two type names would conflict and throw an error. |
|
Exactly! I just want my images references working. Nothing else. I handle all the compression etc ahead of time before I commit my source images. I'll add this to gatsby-transformer-sharp. The couple of minutes gets annoying when developing rapidly and clearing the .cache and public folder when needed. Also, images aren't reprocessed on subsequent runs on the local machine but if I have other developers on the project, they have to wait also. I'd rather have all my images processed once and just process my source images. There's no reason for them to ever need to be processed again in exactly the same way in my opinion. Also when I run into Sharp errors that prevent my build, I'd rather not have Sharp involved at all because I don't actually need or want it. In regards to the node type name, that makes perfect sense! I will remember that for any plugins I create in the future! Also for what it's worth, I think |
|
Here you go! #1556 |
I think the right solution here is to make GraphQL queries run on demand in development. Right now all queries for the entire site are run when starting the development server. Right now this mostly clearly causes trouble for processing images since that's the slowest data transformation right now but there'll be other slow data transformations + for really large sites, even very fast transformations will start to feel slow. BTW, you should never need to delete public. Is there a reason you're doing that? Clearing the .cache directory should only be necessary when building custom transforms and even that should eventually be able to be avoided once we add support for partial cache invalidation e.g. trace a change to a plugin to the nodes it touches. |
|
Haha There's no particular reason at all. I just knew that stale data was causing me frustration so I deleted anything that could be the culprit. Wasn't sure if it was the .cache or the public folder. All that makes perfect sense though. |
|
:-) Yeah, would love to do a deep dive on improving caching sometime... sigh. |
|
Haha sounds like a lot of work. Still awesome as-is though. |
I kept running into issues with Sharp. In my case I didn't really need sharp and things build much faster without it.
This is a plugin I've been using locally to avoid sharp entirely.