Closed nayfin closed 2 years ago
Not sure if this applies to the specific packages you're using, but a lot of the ones I've looked into were HTTP/REST wrappers that were offloading the actual image processing work to an offsite API.
e: which ones, btw?
Something change on 1.0.15 that increase the size https://bundlephobia.com/package/browser-image-compression
And everything looks like it was core-js
https://github.com/Donaldcwl/browser-image-compression/releases/tag/v1.0.15
Thanks for concerning about the package size, the package indeed increased in size after adding core-js even though tree-shaking has been applied. We decided to remove core-js for polyfill in this project in the next release. By that time, one may need to load polyfill yourself in order to support older browsers.
Such as:
<script src="https://cdnjs.cloudflare.com/ajax/libs/core-js/3.21.1/minified.min.js"></script>
Thanks for the quick response and fix! I'll close the issue.
v2.0.0 is released, and the bundle size is half now.
ref: https://bundlephobia.com/package/browser-image-compression@2.0.0
Thanks again. I can confirm that it's less than half the size now, down by more than 100k . Here are screen shots of Source Map Explorer results Before fix
After
Firstly thank you for this awesome project. I've been POCing something with a few different client-side image compressors and yours has the best API and feature set I've found. My only qualm is that it is quiet a bit larger than most of the others I've found, though I can't figure out why. I looked through the dependencies and source code and see that the package depends
core-js
which is also a large package, but it looks like your importing fromcore-js
in a tree-shakable way. So I'm confused as to what is causing the bloat.So I guess this issue is really a few question:
Do you know what is causing the package to be so much larger than similar packages?
Are there future plans to reduce bundle size?
If you have some guidance on this I'd be happy to work a PR to help trim it down.
Thanks again