Make tree-shakeable

[kentcdodds]

Explain your use case

Cloudinary is way to big to responsibly include in the browser for typical use cases: https://bundlephobia.com/package/cloudinary@1.26.2

In particular, all I want is the url utility to make it easier for me to construct URLs with cloudinary. But it's just too big to include in my client-side bundle.

Describe the problem you’re trying to solve

I have a bunch of images for my website that are all hosted on cloudinary. Various parts of my site need to use the same image with different optimizations. I'd like a type-safe utility for constructing these URLs.

Do you have a proposed solution?

From the look of the project, this would be a nontrivial change. But basically my suggestion is to export an ES module built version of the library and export the utility functions individually.

[kentcdodds]

FYI, I found cloudinary-build-url, which handles my use case, but I'll leave this open because it would be really nice to have this from the official package.

[igy]

Hi Kent,

Thanks for opening this.

The new 'V2' versions of our client-side SDKs, which are being released in beta at the moment, are more modular and use a different structure that should assist with most of your concerns about package weight, including being 'tree shakable': https://cloudinary.com/documentation/javascript2_integration#full_example

I think it's unlikely we'll try to make the Node SDK specifically very modular in the same way, because it's intended for server-side use where package weight is less of a concern, but it's likely that the next iteration of the Node SDK will use some methods from our v2.x Core JS library. I've linked the documentation for that library above, and you can find the code here: https://github.com/cloudinary/cloudinary-js-base

Regarding the URL-generation methods, the cloudinary-build-url project you linked is a personal project from a former Cloudinary employee, and it includes some lightweight methods for some of the most common use-cases, some of which can't be added to our own SDKs for practical reasons.

For example, it has options for taking an existing delivery URL and splitting it into its component parts and those work well in many cases, but it's not part of any of our official SDKs because there are many edge cases that make it difficult or impossible to unambiguously parse the URL without more context about an account's settings.

I've seen some good feedback about that project, however, and for your use-case specifically of URL generation with minimal overhead, I think it's a very good option.

For this issue, I'm going to close it for now, but I've shared the feedback with our SDK team to consider when building the v2.x branch of the Node SDK, and in the meantime you should be able to use Maya's cloudinary-build-url project, or the new 'base' JavaScript SDK, depending on what you need

Thanks, Stephen

[kentcdodds]

Oh, that's super to see. I missed that somehow. I don't mind so much about the size for the NodeJS side either 👍

Thank you!

[igy]

You're welcome; thanks for contacting us :)