Very large bundle size

[smithki]

According to Bundlephobia, the bundled package size is quite large (10kb gzipped!)

If only the required APIs from crypto are included, the bundle size reduces to a much more reasonable 1-2kb gzipped. It would be great if the crypto require could be tree-shaken!

[addaleax]

@smithki PRs are welcome! This module is not very actively maintained otherwise, though.

[panva]

Well, it'd be great if the published package didn't include the test folder and dist/object_hash_test.js and other developer flow related files like gulpfile, karma, bower, travis, etc...

[panva]

#92 handles removing the extra clutter. @smithki's concern could also be solved but it would require that the browser bundle is transpiled using something else than deprecated gulp-browserify that doesn't support the destructuring syntax that would (maybe?) make it tree-shaken?

[smithki]

I’m a big proponent of microbundle. If the project maintainers are not opposed to replacing the build system, it’s a solid option that can solve this issue without any configuration.

[smithki]

I would be willing to make a PR, but I don’t want to overstep if this is out of scope for the maintainers.

[addaleax]

@smithki Generally, anything that doesn’t affect consumers of this module should be just fine

[jburghardt]

Any progress on this?
i could help out , depending on whether @smithki is already working on it.
i dont have time to rework the whole build system, but could implement gulp-rollup, (or something similar?) which would just change how the browser bundle is build.

[smithki]

@jburghardt -- So sorry, things are busy for me at the moment. I don't think I'll get to this anytime soon. You're welcome to take it on.

[jburghardt]

Bumping this issue. pull request is pending.

[addaleax]

PRs are still welcome.

[jburghardt]

#94

[atomicpages]

Any interest in an ESM version for tree-shaking support? I'd be happy to send a PR for this 😄

[bybraveHQ]

Update for people finding this: the ~10 KB (gzipped) came from bundling crypto-browserify. It can't be tree-shaken away meaningfully because the library needs synchronous digests, and Web Crypto can't replace it either (async-only, no md5).

I maintain an actively developed fork (@bybrave/object-hash2) where 4.0.0 drops the polyfill entirely: the browser build ships compact built-in md5/sha1/sha256 (fuzz-checked byte-identical to node:crypto), bringing the bundle to 4.5 KB gzipped — and, as a side effect, browser hashes now match node hashes exactly (upstream #62). In node the fork keeps using the native node:crypto.