Skip to content

feat: Updating SDK initialization #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

jurevans
Copy link
Collaborator

@jurevans jurevans commented May 14, 2025

NOTE this also incorporates changes from the following (since the opening of this PR):

After much experimenting and testing, and considering all of the variants of the SDK developers may require, I think we should split up the various target builds into separate published packages. The repo could look like the following:

dist/ # Contains one of the various builds at any given time
crate/ # Rust src
scripts/ # Common build scripts
packages/
  lib/ # @namada/lib - Current SDK TS wrapper code
  sdk/ # @namada/sdk - Default target (single-core web with optional inline loading)
  sdk-multicore/ # @namada/sdk-multicore - Same but with a multicore wasm build
  sdk-node/ # @namada/sdk-node - NodeJS single-core
  wasm/ # @namada/wasm - Where the assets built by `wasm-pack` will live along with supporting types & TS

The public packages having their own package.json and implementation of initSdk() specific to the target will greatly simplify the packaging, as each published package will essentially be the same structure, only with the changes needed to support that particular build. Doing this means that developers only need to install one SDK build depending on their needs instead of all.

Packages published to NPM

  • @namada/sdk
  • @namada/sdk-multicore - I think with some craftiness this could be combined with the normal web SDK, however, it means we publish with two builds, and types would need to be refactored a bit to account for this. Might be more trouble than it's worth right now
  • @namada/sdk-node

Splitting these up will allow us to publish incrementally as each one is tested.

@jurevans jurevans self-assigned this May 14, 2025
@jurevans jurevans force-pushed the feat/refactor-wasm-loading branch 2 times, most recently from 9bdffd3 to 8c81462 Compare May 14, 2025 16:46
@jurevans jurevans changed the title feat: Updating wasm loader feat: Updating SDK initialization May 14, 2025
@jurevans jurevans added documentation Improvements or additions to documentation enhancement New feature or request labels May 15, 2025
@jurevans jurevans force-pushed the feat/refactor-wasm-loading branch 2 times, most recently from 2dd3dc6 to 1281430 Compare May 15, 2025 16:24
@jurevans jurevans force-pushed the feat/refactor-wasm-loading branch 3 times, most recently from cd21d60 to ab44d89 Compare May 19, 2025 13:25
@jurevans jurevans force-pushed the feat/refactor-wasm-loading branch from ab44d89 to 4cd0bb5 Compare May 20, 2025 10:45
@@ -169,7 +169,7 @@ mod tests {
#[wasm_bindgen_test]
fn can_verify_stored_hash() {
let password = "unhackable";
let argon2 = Argon2::new(password.into(), None, None)
let argon2 = Argon2::new(password.into(), None, Some(Argon2Params::new(4096, 3, 1)))
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

default params in Argon2 lib have changed, so I made these explicit to pass

@jurevans jurevans force-pushed the feat/refactor-wasm-loading branch from 7156a7c to 5af54ba Compare May 22, 2025 17:17
@jurevans jurevans force-pushed the feat/refactor-wasm-loading branch from 5ea2c25 to 40eb173 Compare June 9, 2025 09:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant