remove lodash dependency

[infinityfarm]

Is there a reason for this heavy dependency, and why doesn't it manage it's own dependencies in its package.json?

[infinityfarm]

@tocker @taragano The manner in which lodash is being required by this package pulls in the entirety of lodash at least in the case of using webpack as a build tool. This makes lodash the #1 largest dependency in my app the moment I import 'cloudinary-core'. Is there a way we can open a ticket towards remedying this?

[brettcohen]

bumping the above question - experiencing same issues.

[tocker]

Hi @infinityfarm and @brettcohen, If you don't need the full lodash library, import the shrinkwrap library (version >= 2.0.8) or even the minified. The shinkwrap library includes only the subset of lodash functions actually used by the cloudinary library.

var cloudinary = require('cloudinary-core/cloudinary-core-shrinkwrap');
// or
var cloudinary = require('cloudinary-core/cloudinary-core-shrinkwrap-min.js');

The result:

655K  bundle.js - require('cloudinary-core')
265K  bundle.js - require('cloudinary-core/cloudinary-core-shrinkwrap')
123K  bundle.js - require('cloudinary-core/cloudinary-core-shrinkwrap-min.js')

[infinityfarm]

@tocker thanks, trying that out..

[marcohamersma]

I also stumbled upon this issue after seeing my bundle size for a lightweight site go from about 500kb to 2,3mb. Implementing the shrinkwrapped version did not really work for my project, and leads to _ is not defined errors.

I feel that if you make a utility library like this, you could be a bit more responsible in considering what might be uselessly sent over to some end user's computer.

Is it no option for you to only include the functions from lodash that you actually need in your package, for example with the official modularised modules?

I'd do it myself and make a pull request, but the repo seems to contain no source files, only the compiled end files.

[tocker]

@marcohamersma the shrinkwrapped version is built similarly to the modularized lodash packages but it is more concise. Can you please share the full error of _ is not defined?

[marcohamersma]

Hello @tocker, I've kinda moved along from this problem by using another library, so I can't easily reproduce a stack trace for you at the moment. I should probably have included this in the first place, sorry about that 🙁.

[idanwe]

I'm also really want to avoid of adding big dependency to my app, especially that the image upload is mainly used from mobile devices.

@marcohamersma which library do you use?

@tocker Is their an option to use plain http/xhr requests to upload files?

[idobarnoam]

@idanwe Its possible use plain HTTP request to upload images as described here.

You could also try the shrinkwrapped version for a smaller bundle.

Makes sense?

[idanwe]

Yes, I find the use of the plain http API better for me, the shrinkwrapped version is better but steal for me it doesn't benefit enough to use it (I can replace it with few lines of upload code and few transformations that I used regularly in my app). (and other issue that I had that it is override the global _ variable)

Thanks for taking the time to clarify.

[idobarnoam]

Glad I could help.

If you have any further questions, please feel free to contact us at support@cloudinary.com

[marcohamersma]

@idanwe I use a slightly modified version of https://www.npmjs.com/package/withlocals-cloudinary (I forgot not why I don't use the module directly)

[jwerre]

This requires lodash to be modularized so if I want to use this I have to have both a stand build and modularized version of lodash in my project.