Set version ranges using ^ in package.json to deduplicate transitive dependencies

[thehenrytsai]

Background:

This ask came from #315.

The original intent of version lock was to prevent any chance of unexpected dependency issues. But if it deals more pain by default, a case (the above referenced issue) can be made to relax the restriction.

The alternative is to have mono-repos and locking our dependency versions between projects. But this approach will not help with externally managed projects like ion-tools in which case we will need to fork.

Task Details:

1. Update all dependencies in package.json to latest
2. Relax version restriction by adding ^ to the version number

Picking Up This Issue:

• If you'd like to work on this, please comment "picking this up" below, and I'll assign the issue to you

Questions:

• If you need assistance or clarification, feel free to comment below.
• Feeling overwhelmed? Join our #hack-together channel and collaborate with a buddy.
• New to open-source? Check out our Hacktober #getting-started channel.
• Leaderboard: Check your ranking after finishing this task.

Resources:

• Creating a Pull Request: If you're new to GitHub and unsure how to create a pull request, follow this step-by-step guide.

Remember, communication is key! If you have any questions or face any challenges, we're here to help so please don't hesitate to reach out.

Good Luck! 🍁

[shamilovtim]

Some examples of why we shouldn't be locking to exact versions in our SDK consumed by other users:

2 versions of @nobile/ed25519, 3 versions of @noble/secp256k1,

2 versions of secp256k1 (and isnt this already a duplicate of the above secp256k1 package?)

a whopping 3 versions of readable stream, which was already 220kb. this is 1.3mb worth of readable-stream

3 versions of multiformats worth a whopping 3.6 megabytes:

and this is the best case scenario since i ran this in a prototype. in an end user's package they'll have even more duplicates since they'll be using other packages from the community

[shamilovtim]

locking to exact versions makes sense for a product but does not make sense for a library which depends on other libraries which recursively depend on other libraries

[Petsamuel]

picking this up

[EbonyLouis]

@Petsamuel Assigned 🥳 good luck!

[diehuxx]

We've decided that version ranges aren't worth it for us right now. The potential benefits of slimming package size don't outweigh the risk of introducing breaking changes in upstream deps or causing inconsistent issues that result from local package versions being different depending on when someone runs npm install. In the future, when we revisit package size optimization, we'll revisit this issue.