cloudinary
cloudinary copied to clipboard
Package size increase
Hi,
First, I'd like to thank you for the amazing work you're doing here !
Since the 1.0.0
version release, package size has increased by a factor of 50, which is a lot. I understand the need for a better API but since Cloudinary purpose is to optimize images & videos, it is unfortunate for this module to grow that way.
https://bundlephobia.com/result?p=@nuxtjs/[email protected]
I noticed it is due to the addition of the main cloudinary library which double in size recently.
https://bundlephobia.com/[email protected]
Is anything can be done to reduce that size increase ?
Regards
Hi @gaelreyrol
Thank you so much for your words and reporting the issue. It means a lot to me 👍 😄
About the bundle size, yes the problem is known and it's a common problem for almost any package using cloudinary core
and cloudinary
.
I'm currenlty working on a better approach to reduce the bundle size at the moment, such as removing and replacing the dependencies with a lighter one. It will be included in the next release 1.0.3 and it's scheduled to release some time next week. Please be patient in the mean time :).
If you would like to contribute, please let me know :). And please continue sending me feedback or suggestion if you have any. ❤️
Have a nice week! :)
Thanks for the fast reply and your concern about this issue.
Indeed, it seems most of the work to do is on the cloudinary
package, maybe the best thing to do is to avoid it because it is not meant to be used on the client side ?
I can't find the part of the code that depends on this package, am I missing something ?
I don't think cloudinary
is the culprit, mostly cloudinary-core
tbh.
cloudinary
is loaded dynamically whenever user calls the server side upload
, explicit
. On client side, explicit
call does not exist, and upload
will already automatically fall back to upload
api call for client side one, which does not rely on cloudinary
package.
/* cloudinary-api.js */
const cldServer = require('cloudinary').v2
On client side, only cloudinary-core
will be loaded which does the url calculation and is pretty heavy. cloudinary
will not present there afaik.
Also, it seems to me like bundlephobia.com is not 100% accurate. For example, from 0.0.8 till 0.0.11, there is cloudinary-core
dependency presented in the module, and the analyzing doesn't detect the size of it. Instead it went for consola
(78%) and self code (21%). In v1.0.0, cloudinary-core
suddenly appears in the analysis result with 18-19%, while cloudinary
took 20%. But cloudinary
is lazy-loaded, and cloudinary-core
is not.
Hence that does not make any sense. Unless I'm missing something here, since I'm not familiar how bundle phobia works tbh.
In the other hand, https://packagephobia.com/result?p=@nuxtjs/[email protected] shows me a more consistent result between versions.
I'd like to echo my gratitude for the quick responses!
For what it's worth, I've noticed an increase in size as well. Running this Webpack visualizer via nuxt build --analyze
, I'm clocking in at around 220k actual / 617k raw. And I'm only using it on one route. It's far larger than the big homepage hero image I'm loading.
Also worth noting that the analyzer says cloudinary
is about 25% heavier than cloudinary-core
.
These are what I have installed:
@mrcsmcln Indeed. cloudinary
is a Node.js package than runs on server side. So it should not affect the application on the client-side.
However, I'm removing the dependency to cloudinary
and cloudinary-core
since they are kind of duplicate each other in certain functionalities, and there are some functionalities should have more optimized.
Hopefully I will get a new release version this week for this problem :).
This is now large enough that it fills up 50% of my vercel serverless function size...
Because of that I'm going to be rolling it by hand instead.
Hey, I am closing this issue as it is targeting the v1 version and it is really old (more than one year stale)