make node transformation optional depending on boolean like older version

[amcc]

Hi I added an issue - but perhaps its actually a feature request. However we have a back compatibility issue where we have cloudinary nodes with cloudinaryAssetData = false on them - which ran fine in gatsby v3 with an older version of this module.

I'd be happy to try to patch/customise the module somehow - but may need some help. Putting this flag back in as an option would be handy however.

Here's the issue - if this is more relevant as a discussion then i can transfer the info over here:
#223

many thanks for any help you can give

[raae]

Thank you so much for reporting 🙏

We'll figure out the best way forward and have a solution within the week.

[amcc]

great thank you - let me know if you need a test repo or anything else to help you out

[raae]

I would love a test repo that reproduces the problem yes.

[amcc]

great thanks. I just added you to a minimal repo - this should have the same symptoms on build

[raae]

I have reproduced and found the bug, pesky undefined metadata response from Cloudinary we did not account for. Will have a fix out by tomorrow.

Question: Would you like to get an error or warning when there is a Cloudinary datashape that is valid, but no longer exists? None will break the build by itself.

[amcc]

i think the issue with the errors from cloudinary (i.e. 404 / undefined type) if they aren't build breaking would be better as warnings, anything red/error normally says "your build will fail"!

The more worrying error (which is actually breaking the build) is the width undefined in gatsbyimagedata and similar. I'm assuming this is where the plugin, or something down the line, is expecting an image where none was created.

Did you manage to test with the repo i shared - you should see the build breaking error there. Anything else i can do? And thanks so much for the help!

[raae]

Yes, I have reproduced and found the bug, pesky undefined metadata response from Cloudinary we did not account for. Will have a fix out by tomorrow.

[raae]

Thank you so much for the repo, super helpful!

[raae]

I have fixed the bug, but came across the edge case below asked in #225 (comment)

[raae]

This unearthed an underlaying issue I want to be mindful about fixing. I'll keep you posted.

[raae]

What do you expect when the asset referenced is a multipage document? To have it be ignored or to create an image asset from it?

[amcc]

Anything not an image doesn't need to be a Gatsby image for us. PDFs / videos and other docs are handled differently.

Although if cloudinary is capable of generating a an image preview from non image types I can see a good use case for that. We store the mime type so we can distinguish things, I wonder if everyone else will.

On balance ignoring them is perhaps easiest for our use case

[raae]

I am thinking that generating a preview would be the correct path, if someone is asking for gatsbyImage on a video or pdf asset then they should get that.

[amcc]

makes sense - having an image there could be beneficial in the future for us and certainly wont break anything

[raae]

The bug breaking your build should be fixed. However under the current implementation to skip it from trying to resolve gatsbyImage you'll either get your cloudinary data to be null/undefined, or to set both publicId and cloudName to null/undefined. Does that work for you @amcc?

[amcc]

I'll give this a go tomorrow. But probably all ok. Thank you for all the effort!

[amcc]

just tried it - builds fine in the full site, so all working great.

As i understand it do you mean that to skip creating gatsbyImageData I either set cloudinaryAssetData to false/null/undefined, or both the cloudName and publicId to null/undefined.

right now i think our system is both setting cloudinaryAssetData to false and cloudName and publicId to null/undefined.

Either way its working - but good to know the exact necessities. Could you also point me to the file where this is set - would be good to look at the relevant code to try to understand it :) Many thanks again!

[raae]

Currently you need to set cloudName and publicId to null/undefined, or the whole object to null/undefined.
If there is a cloudName and publicId, but invalid or missing originalWidth and originalHeight there will be a network request for metadata. If that fails, gatsbyImage will resolve to null. So it works, but you'll have an "unnecessary" network request if you already knew it would not work.

For your vimeo videos the data shape works, as cloudName and publicId is null.

{
  "filename": "https://vimeo.com/720790340",
  "cloudinary": {
     "cloudinaryAssetData": false, // ignored
     "originalHeight": null,
     "originalWidth": null,
     "publicId": null,
     "cloudName": null,
     "gatsbyImageData": null
   }
}

For your cloudinary videos with originalWidth and originalHeight no "unnecessary" network request will be made, but gatsbyImageData will resolve to broken images. If you don't use them that is not a problem. Hoping to make it resolve to proper images of the first frame in the future.

{
  "filename": "https://res.cloudinary.com/rca2020/video/upload/v1663873049/rca2022/631b0fd162dbd9e52062748d-47483.mp4",
  "cloudinary": {
    "cloudinaryAssetData": false, // ignored
    "originalHeight": 1080,
    "originalWidth": 1920,
    "publicId": "rca2022/631b0fd162dbd9e52062748d-47483",
    "cloudName": "rca2020",
    "gatsbyImageData": {broken images}
  }
} 

But for your Cloudinary pdfs with originalWidth and originalHeight set to -1 a network request will be made as there is both a cloudName and publicId, but the metadata is invalid. However the resolved gatsbyImageData is a valid image of the first page. So if the metadata network request is unnecessary depends on if you are planning to use the image or not.

{
  "filename": "https://res.cloudinary.com/rca2020/image/upload/v1663591030/rca2022/631b3f3f62dbd9e5206706cd-29702.pdf",
   "cloudinary": {
     "cloudinaryAssetData": false, // ignored
     "originalHeight": -1,
     "originalWidth": -1,
     "publicId": "rca2022/631b3f3f62dbd9e5206706cd-29702",
     "cloudName": "rca2020",
      "gatsbyImageData": {valid images}
  }
} 

[olavea]

Hi there @amcc !

How do you feel about a chat about these new plugins? My email adress is ola@lillylabs.no.

We are currently interviewing plugin users and customers to put together a roadmap for the future of these two plugins.

I'll write more info in an email.

All the best

Ola Vea

P.S.
I work with Queen @raae and when I say "we" I mean her and me.