Swap create-hash for hash.js sha256

[mankins]

High Level Overview of Change

Swap create-hash sha-256 implementation for hash.js which works in more environments.

Context of Change

I was getting an error similar to browserify/createHash#30 and found that swapping out the implementation fixed the referenced error. I see hash.js is used in other parts of the xrpl ecosystem too.

Type of Change

• Refactor (non-breaking change that only restructures code)

Before / After

There should be no change to existing running code. This allows the code to be run in more ecosytems (such as Tauri + Sveltekit where I'm running this).

Test Plan

Existing tests pass.

[justinr1234]

@mankins The issue is this: browserify/cipher-base#11

So changing to a package that works well in the browser is a great solution.

[justinr1234]

Also it seems like you probably need to add the polyfill for stream anyways.

In webpack that would look like:

resolve: {
        alias: {
            stream: 'stream-browserify'
        }
    },

These polyfills are typically used by other libraries as well, such as web3.js

[mankins]

Also it seems like you probably need to add the polyfill for stream anyways.

You mean on my app, right? I haven't needed that yet, but good to know.

Let me know if I should do anything else here.

[ckniffen]

@mankins did you try adding those polyfills configuration in our docs?

My hesitation with making this switch is it does not eliminate create-hash as a dependency it mere adds another one. Below are all the other places create-hash will still be required.

[mankins]

@mankins did you try adding those polyfills configuration in our docs?

Some context: I was doing this for ripple-address-codec not xrpl.js. This is now a mono repo for some npm packages, right? (or am I in the wrong place?)

I'm not sure which polyfills in your docs you were referring to (the stream one above? how does that relate to ripple-address-codec? I added polyfills via vite (not webpack), but was able to solve this by changing the dependency. It's possible I didn't do that right so if I need to I can try again.

My hesitation with making this switch is it does not eliminate create-hash as a dependency it mere adds another one. Below are all the other places create-hash will still be required.

I'm seeing hash.js already in use in ripple-keypairs.

I could also expand the PR and change out the rest if that would get this merged.

[ckniffen]

I'm seeing hash.js already in use in [ripple-keypairs](https://github.c> I could also expand the PR and change out the rest if that would get this merged.

Good point. I didn't not realize that. In that case can you update ripple-keypairs's version to be ^1.0.7 as well>

[mankins]

In that case can you update ripple-keypairs's version

Ok, updated.

[sublimator]

when I originally made this library, the hash function was configurable iirc
"bring your own hash" :)

hashjs will be a bit of a perf drop for some use cases ?

[mankins]

That would be nice, but is it still configurable? I didn't see that option.

For the record I'd prefer a library that looks for native crypto support and uses that, falling back to a trusted implementation that will work in all environments. create-hash almost does this, but it requires manually choosing one implementation or another rather than falling back. I also prefer the more standard signature createHash('sha256').update(... ... of course I just want the package to work because I'd rather use it than not.

[sublimator]

Strange, createHash should use crypto when running on node, then use the "browser" versions in the browser.
Maybe you are using it in a strange environment and are missing some polyfills that some build tools like webpack usually automatically bundle.

[mankins]

I think it's because it's compiled for Tauri ... you're right though I should try to get that working again. I had seen this as a quick route without downsides, but maybe that's not the case in practice.

[sublimator]

Was ///years/// ago 2015

[mankins]

I'm going to close this, as it's stale and I got the library working with more polyfilling as suggested above.

Would be cool to make createHash configurable as suggested above, but that will likely be another pr.