feat(js): use buffer instead of text-decoder

[berendsliedrecht]

• Do not depend on fast-decoding anymore
• added simple example app which can be used for testing.
  • NOTE: it is currently rather annoying to fully recompile aries-askar for all the android and iOS architectures so we would have to find a solution for that.

This is by no means a perfect app for testing and if we would rather wait for a better testing app I can remove it from this PR and create it later.

Ideally I would like to move to use pnpm as it makes dealing with workspaces a whole lot easier. And create some way to "quickly" (still need to compile askar like 6 times...) use custom askar builds.

[andrewwhitehead]

Looks like the workflow needs to switch to node 18

[TimoGlastra]

This file should not be removed I think?

Otherwise when you run yarn install it will automatically download the binaries, which you may not want

[berendsliedrecht]

For the React Native Example to be used without building it locally it is required now. It is not optimal, agreed.

[TimoGlastra]

I think it'd fail if we increase the native binary version. As the CI will then try to install the native binary, but it doesn't exist yet

[andrewwhitehead]

Being required to build it locally doesn't seem like a bad thing to me, is there a reason we don't want to do that?

[berendsliedrecht]

The main reason right now is that cross only allows to be ran on a Linux host which would make building the application for Android on macOS or Windows impossible. With a better example app we could add something where you specify the platform and you can choose to only build the application for iOS which would make it work on macOS.

[andrewwhitehead]

I'm trying to test this out but haven't gotten very far yet. A few things I've noticed (trying the ios build):

• Commands like yarn build from the root directory produce an error, as they aren't defined by the app package
• I had to add "uuid": "3.4.0" to the package dependencies to work around this issue: SDK45: Unable to resolve module uuid/v5 in expo go expo/expo#17261
• I had to remove "@types/react" from aries-askar-react-native as it was producing duplicate type definitions

At the moment I'm stuck on this error. I think I need to build the iOS framework and put it somewhere, maybe under /ios?

Edit: It looks like I can bypass this issue by running yarn ios instead of yarn expo > open iOS simulator, and then I was able to run the application.

[berendsliedrecht]

I'm trying to test this out but haven't gotten very far yet. A few things I've noticed (trying the ios build):

• Commands like yarn build from the root directory produce an error, as they aren't defined by the app package
• I had to add "uuid": "3.4.0" to the package dependencies to work around this issue: SDK45: Unable to resolve module uuid/v5 in expo go expo/expo#17261
• I had to remove "@types/react" from aries-askar-react-native as it was producing duplicate type definitions

At the moment I'm stuck on this error. I think I need to build the iOS framework and put it somewhere, maybe under /ios?

Edit: It looks like I can bypass this issue by running `yarn ios` instead of `yarn expo > open iOS simulator`, and then I was able to run the application.

Hmmm, maybe I should not have added the example app just yet. Setting it up where it is easy to change the askar libraries and build it will require some more effort.

I think for now the best we can do is just to remove the example app and create a PR later with it which will include a simple script which can build the libraries and place them in the correct location.

[berendsliedrecht]

I removed the example application as it was not ready to be merged. Will need to do some research for how we can properly set this up.

[berendsliedrecht]

@genaris any idea what is going on here? https://github.com/hyperledger/aries-askar/actions/runs/6089025819/job/16534903694 seems to refer to your patched version of the library.

[genaris]

@genaris any idea what is going on here? https://github.com/hyperledger/aries-askar/actions/runs/6089025819/job/16534903694 seems to refer to your patched version of the library.

I think there is an issue when yarn tries to resolve types for @2060.io/ref-napi (direct dependency) and types for ref-napi (it seems that @types/ref-array-di is requiring it). Both link to the same (as we use "@types/2060.io__ref-napi": "npm:@types/ref-napi")
so yarn complains with ... is trying to unpack in the same destination "xxx" as pattern ["xxx"]. This could result in a non deterministic behavior, skipping..

In this PR, the entry for @types/ref-napi in yarn.lock was removed. If I manually re-add it, it works. Not sure yet what's the right approach here to force these types before this breaks again. Maybe we'll need to patch @types/ref-array-di as well or create an actual @types/2060.io__ref-napi in DefinitelyTyped repo?

[genaris]

@genaris any idea what is going on here? https://github.com/hyperledger/aries-askar/actions/runs/6089025819/job/16534903694 seems to refer to your patched version of the library.

Update on this: I've added type definitions to the packages in order to attempt types clashing. Changes in nodejs' package.json would look like this:

I've tested it locally (build, check-types, test, etc.) from a clean checkout and seems to work fine. Hope this can help to unblock this PR!