feat(sdk): add automatic entropy generation for document creation #2839
Conversation
Walkthroughcreate() in DocumentsFacade now accepts an optional entropyHex and auto-generates a 64‑char hex entropy when omitted. A new generateEntropy() util was added to produce 32 bytes (64 hex chars) of cryptographically secure entropy. Tests updated/added to cover forwarding and generation behavior. Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant DocumentsFacade
participant generateEntropy as EntropyUtil
participant wasmSdk as DocumentCreate
Caller->>DocumentsFacade: create(args {..., entropyHex?})
alt entropyHex provided
DocumentsFacade->>wasmSdk: documentCreate({... entropyHex ...})
else entropyHex missing
DocumentsFacade->>EntropyUtil: generateEntropy()
EntropyUtil-->>DocumentsFacade: entropyHex (64‑char hex)
DocumentsFacade->>wasmSdk: documentCreate({... entropyHex ...})
end
wasmSdk-->>Caller: Promise result
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai full review |
✅ Actions performedReview triggered.
|
✅ Actions performedFull review triggered. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/js-evo-sdk/src/util.ts (1)
16-19: Consider removing likely dead code.In Node.js,
globalThis.cryptoprovides the Web Crypto API, which includesgetRandomValuesbut notrandomBytes. TherandomBytesmethod is specific to the Node.jscryptomodule (accessed viaimportorrequire), notglobalThis.crypto.This branch will likely never execute, though the function still works correctly via the
getRandomValuespath below (lines 22-26).Consider removing this branch or replacing it with a proper Node.js crypto module import if Node.js-specific optimization is desired:
- // Node.js environment - if (typeof globalThis !== 'undefined' && globalThis.crypto && 'randomBytes' in globalThis.crypto) { - // @ts-ignore - Node.js crypto.randomBytes exists but may not be in types - return globalThis.crypto.randomBytes(32).toString('hex'); - } -packages/js-evo-sdk/tests/unit/util.spec.mjs (1)
51-59: Consider usingslice()instead of deprecatedsubstr().Line 56 uses
substr(), which is deprecated. While it still works, preferslice()orsubstring()for better future compatibility.Apply this diff:
- bytes.push(parseInt(entropy.substr(i, 2), 16)); + bytes.push(parseInt(entropy.slice(i, i + 2), 16));
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/js-evo-sdk/src/documents/facade.ts(2 hunks)packages/js-evo-sdk/src/util.ts(1 hunks)packages/js-evo-sdk/tests/unit/facades/documents.spec.mjs(2 hunks)packages/js-evo-sdk/tests/unit/util.spec.mjs(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
packages/**/tests/**
📄 CodeRabbit inference engine (AGENTS.md)
Place unit and integration tests alongside each package in packages//tests
Files:
packages/js-evo-sdk/tests/unit/facades/documents.spec.mjspackages/js-evo-sdk/tests/unit/util.spec.mjs
packages/**/**/*.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
packages/**/**/*.{js,ts,jsx,tsx}: Adhere to ESLint with Airbnb/TypeScript configs for JS/TS code
Use camelCase for JS/TS variables and functions
Use PascalCase for JS/TS classes
Prefer kebab-case filenames within JS packages
Files:
packages/js-evo-sdk/src/documents/facade.tspackages/js-evo-sdk/src/util.ts
🧠 Learnings (7)
📓 Common learnings
Learnt from: thephez
PR: dashpay/platform#2754
File: packages/wasm-sdk/api-definitions.json:1285-1285
Timestamp: 2025-09-03T19:33:21.688Z
Learning: In packages/wasm-sdk/api-definitions.json, thephez prefers to keep the existing "ripemd160hash20bytes1234" placeholder for ECDSA_HASH160 data field in documentation examples rather than using a valid base64-encoded format, maintaining consistency with the previous documentation approach.
Learnt from: thephez
PR: dashpay/platform#2754
File: packages/wasm-sdk/docs.html:0-0
Timestamp: 2025-09-03T15:44:33.889Z
Learning: In packages/wasm-sdk/docs.html, thephez prefers to keep realistic-looking private key placeholders in documentation examples rather than using obvious fake placeholders, despite secret scanner warnings.
📚 Learning: 2025-07-28T20:00:24.323Z
Learnt from: QuantumExplorer
PR: dashpay/platform#2711
File: packages/wasm-sdk/docs.html:2359-2383
Timestamp: 2025-07-28T20:00:24.323Z
Learning: In packages/wasm-sdk/docs.html, QuantumExplorer confirmed that placeholder private keys in documentation examples are acceptable as they are not real keys, though field name accuracy for the SDK API should still be maintained.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/documents.spec.mjs
📚 Learning: 2025-09-22T05:59:31.140Z
Learnt from: shumkov
PR: dashpay/platform#2783
File: packages/js-evo-sdk/tests/functional/dpns.spec.mjs:2-2
Timestamp: 2025-09-22T05:59:31.140Z
Learning: The dist/evo-sdk.module.js file in packages/js-evo-sdk is a generated build artifact created during the build process, not a source file that should exist in the repository.
Applied to files:
packages/js-evo-sdk/tests/unit/util.spec.mjs
📚 Learning: 2025-09-12T13:18:08.661Z
Learnt from: CR
PR: dashpay/platform#0
File: AGENTS.md:0-0
Timestamp: 2025-09-12T13:18:08.661Z
Learning: Applies to packages/**/tests/**/*.{js,ts,jsx,tsx,rs} : Name tests descriptively, starting with “should …”
Applied to files:
packages/js-evo-sdk/tests/unit/util.spec.mjs
📚 Learning: 2024-10-18T15:37:21.329Z
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Applied to files:
packages/js-evo-sdk/tests/unit/util.spec.mjs
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
PR: dashpay/platform#2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/js-evo-sdk/src/documents/facade.ts
📚 Learning: 2024-10-24T04:58:02.843Z
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Applied to files:
packages/js-evo-sdk/src/util.ts
🔇 Additional comments (9)
packages/js-evo-sdk/tests/unit/facades/documents.spec.mjs (2)
56-67: LGTM! Good test coverage for explicit entropy.The test clearly verifies that when
entropyHexis explicitly provided, it's forwarded unchanged to the underlyingdocumentCreatecall. The updated test name improves clarity.
69-95: LGTM! Comprehensive test for auto-generation.The test thoroughly verifies the auto-generation behavior by:
- Confirming
documentCreateis called with all expected parameters- Validating the generated entropy matches the expected format (64 hex characters)
- Ensuring other parameters are forwarded correctly
packages/js-evo-sdk/src/documents/facade.ts (2)
1-1: LGTM! Correct import addition.The import of
generateEntropyis necessary for the new auto-generation feature.
70-90: LGTM! Clean implementation of optional entropy.The changes correctly implement the auto-generation feature:
- Making
entropyHexoptional maintains backward compatibility- Using the nullish coalescing operator (
??) ensures entropy is auto-generated only when not provided- The implementation is concise and clear
packages/js-evo-sdk/src/util.ts (2)
7-13: LGTM! Clear documentation.The JSDoc clearly describes the function's purpose, return value, and error conditions.
22-36: LGTM! Core implementation is correct.The
getRandomValuespath (lines 22-26) works correctly in both modern Node.js and browsers. The hex conversion properly pads each byte to two characters.The
window.cryptofallback (lines 29-33) is redundant in modern environments sinceglobalThis.cryptoandwindow.cryptoare equivalent in browsers, but keeping it improves compatibility with older environments at minimal cost.packages/js-evo-sdk/tests/unit/util.spec.mjs (3)
4-26: LGTM! Comprehensive test coverage for asJsonString.The tests cover all relevant cases: null, undefined, strings, objects, and arrays.
28-50: LGTM! Good coverage of basic entropy properties.The tests effectively verify:
- Correct output length (64 characters)
- Valid hexadecimal format
- Non-deterministic generation (different values each time)
61-76: LGTM! Good statistical validation.The distribution test effectively verifies that the entropy generation produces a good variety of hex digits across multiple samples, helping ensure the randomness quality.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
packages/js-evo-sdk/tests/unit/util.spec.mjs (1)
61-75: Consider raising the uniqueness threshold for better cryptographic quality validation.The threshold of 10 unique hex digits (62.5% coverage) might be too permissive for validating cryptographic randomness. With 640 characters (10 samples × 64 chars), you would typically expect to see all 16 hex digits with high probability.
Consider raising the threshold to ensure better validation:
- // We should see most of the 16 possible hex digits (0-9, a-f) - // With 640 characters (10 * 64), we expect to see all 16 - expect(uniqueChars).to.be.at.least(10); + // We should see most of the 16 possible hex digits (0-9, a-f) + // With 640 characters (10 * 64), we expect to see all or nearly all 16 + expect(uniqueChars).to.be.at.least(14);packages/js-evo-sdk/src/util.ts (2)
28-33: Remove redundant fallback code.Lines 28-33 duplicate the logic from lines 22-26. In modern JavaScript environments where
globalThisis not available,windowalso won't be available. SinceglobalThisis available in all modern browsers and Node.js versions that support the Web Crypto API, this fallback is unnecessary.Apply this diff to remove the redundant code:
// Browser environment or Node.js with Web Crypto API if (typeof globalThis !== 'undefined' && globalThis.crypto && globalThis.crypto.getRandomValues) { const buffer = new Uint8Array(32); globalThis.crypto.getRandomValues(buffer); return Array.from(buffer).map(b => b.toString(16).padStart(2, '0')).join(''); } - // Fallback for older environments - if (typeof window !== 'undefined' && window.crypto && window.crypto.getRandomValues) { - const buffer = new Uint8Array(32); - window.crypto.getRandomValues(buffer); - return Array.from(buffer).map(b => b.toString(16).padStart(2, '0')).join(''); - } - throw new Error('No secure random source available. This environment does not support crypto.randomBytes or crypto.getRandomValues.');
17-17: Consider addressing TypeScript type issues properly instead of using@ts-ignore.The
@ts-ignorecomment suppresses type checking, which can mask legitimate type issues. Consider using proper type assertions or checking if the types can be improved.If the concern is that
randomBytesmight not be in the type definitions forglobalThis.crypto, you could use a type guard or type assertion:// Node.js environment if (typeof globalThis !== 'undefined' && globalThis.crypto && 'randomBytes' in globalThis.crypto) { const crypto = globalThis.crypto as any; if (typeof crypto.randomBytes === 'function') { return crypto.randomBytes(32).toString('hex'); } }However, given that this branch is unreachable (see previous comment), this may be moot if the branch is removed.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/js-evo-sdk/src/documents/facade.ts(2 hunks)packages/js-evo-sdk/src/util.ts(1 hunks)packages/js-evo-sdk/tests/unit/facades/documents.spec.mjs(2 hunks)packages/js-evo-sdk/tests/unit/util.spec.mjs(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
packages/**/tests/**
📄 CodeRabbit inference engine (AGENTS.md)
Place unit and integration tests alongside each package in packages//tests
Files:
packages/js-evo-sdk/tests/unit/facades/documents.spec.mjspackages/js-evo-sdk/tests/unit/util.spec.mjs
packages/**/**/*.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
packages/**/**/*.{js,ts,jsx,tsx}: Adhere to ESLint with Airbnb/TypeScript configs for JS/TS code
Use camelCase for JS/TS variables and functions
Use PascalCase for JS/TS classes
Prefer kebab-case filenames within JS packages
Files:
packages/js-evo-sdk/src/util.tspackages/js-evo-sdk/src/documents/facade.ts
🧠 Learnings (6)
📓 Common learnings
Learnt from: thephez
PR: dashpay/platform#2754
File: packages/wasm-sdk/docs.html:0-0
Timestamp: 2025-09-03T15:44:33.889Z
Learning: In packages/wasm-sdk/docs.html, thephez prefers to keep realistic-looking private key placeholders in documentation examples rather than using obvious fake placeholders, despite secret scanner warnings.
Learnt from: thephez
PR: dashpay/platform#2754
File: packages/wasm-sdk/api-definitions.json:1285-1285
Timestamp: 2025-09-03T19:33:21.688Z
Learning: In packages/wasm-sdk/api-definitions.json, thephez prefers to keep the existing "ripemd160hash20bytes1234" placeholder for ECDSA_HASH160 data field in documentation examples rather than using a valid base64-encoded format, maintaining consistency with the previous documentation approach.
📚 Learning: 2025-07-28T20:00:24.323Z
Learnt from: QuantumExplorer
PR: dashpay/platform#2711
File: packages/wasm-sdk/docs.html:2359-2383
Timestamp: 2025-07-28T20:00:24.323Z
Learning: In packages/wasm-sdk/docs.html, QuantumExplorer confirmed that placeholder private keys in documentation examples are acceptable as they are not real keys, though field name accuracy for the SDK API should still be maintained.
Applied to files:
packages/js-evo-sdk/tests/unit/facades/documents.spec.mjs
📚 Learning: 2024-10-24T04:58:02.843Z
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Applied to files:
packages/js-evo-sdk/src/util.ts
📚 Learning: 2025-09-22T05:59:31.140Z
Learnt from: shumkov
PR: dashpay/platform#2783
File: packages/js-evo-sdk/tests/functional/dpns.spec.mjs:2-2
Timestamp: 2025-09-22T05:59:31.140Z
Learning: The dist/evo-sdk.module.js file in packages/js-evo-sdk is a generated build artifact created during the build process, not a source file that should exist in the repository.
Applied to files:
packages/js-evo-sdk/tests/unit/util.spec.mjs
📚 Learning: 2025-09-12T13:18:08.661Z
Learnt from: CR
PR: dashpay/platform#0
File: AGENTS.md:0-0
Timestamp: 2025-09-12T13:18:08.661Z
Learning: Applies to packages/**/tests/**/*.{js,ts,jsx,tsx,rs} : Name tests descriptively, starting with “should …”
Applied to files:
packages/js-evo-sdk/tests/unit/util.spec.mjs
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
PR: dashpay/platform#2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/js-evo-sdk/src/documents/facade.ts
🔇 Additional comments (7)
packages/js-evo-sdk/tests/unit/util.spec.mjs (1)
3-26: LGTM! Comprehensive test coverage for asJsonString.The tests cover all expected edge cases (null, undefined, string passthrough, object/array serialization) with correct assertions.
packages/js-evo-sdk/tests/unit/facades/documents.spec.mjs (2)
56-67: LGTM! Clear test for explicit entropy forwarding.The test correctly verifies that when
entropyHexis explicitly provided, it's forwarded unchanged to the underlying WASM SDK call.
69-95: LGTM! Comprehensive test for auto-generation behavior.The test thoroughly validates that:
- Entropy is auto-generated when not provided
- All other parameters are forwarded correctly
- Generated entropy matches the expected 64-character hex format
packages/js-evo-sdk/src/util.ts (1)
14-19: Node.jsrandomBytesbranch is unreachable.In Node.js environments,
globalThis.cryptoprovides the Web Crypto API (which includesgetRandomValues), butrandomBytesis a separate method available only throughimport crypto from 'crypto'orrequire('crypto'). The check'randomBytes' in globalThis.cryptowill always fail in Node.js, so this branch will never execute.The current implementation will still work correctly because it falls through to the
getRandomValuesbranch (lines 22-26), which works in both Node.js (v15+) and browsers.If Node.js-specific
randomBytesoptimization is intended, consider importing the crypto module explicitly:export function generateEntropy(): string { // Try Node.js crypto module first (if available) try { // Dynamic import for Node.js compatibility const nodeCrypto = await import('crypto'); if (nodeCrypto && nodeCrypto.randomBytes) { return nodeCrypto.randomBytes(32).toString('hex'); } } catch { // Fall through to Web Crypto API } // Browser/Node.js Web Crypto API if (typeof globalThis !== 'undefined' && globalThis.crypto?.getRandomValues) { const buffer = new Uint8Array(32); globalThis.crypto.getRandomValues(buffer); return Array.from(buffer).map(b => b.toString(16).padStart(2, '0')).join(''); } throw new Error('No secure random source available.'); }However, the current implementation using
getRandomValuesworks correctly in both environments, so this optimization may not be necessary.packages/js-evo-sdk/src/documents/facade.ts (3)
1-1: LGTM! Import correctly updated.The
generateEntropyimport is properly added to support the new auto-generation feature.
70-77: LGTM! Backward-compatible API enhancement.Making
entropyHexoptional is a clean improvement that:
- Maintains backward compatibility (existing code with explicit entropy still works)
- Reduces boilerplate for common use cases
- Provides clear documentation via the inline comment
78-90: LGTM! Clean implementation of auto-generation logic.The implementation correctly:
- Handles
entropyHexseparately from other destructured parameters- Uses nullish coalescing (
??) to generate entropy only when not provided- Passes the resolved entropy value to the underlying WASM SDK call
The logic is clear, concise, and maintains the expected behavior for both explicit and auto-generated entropy.
|
Please rebase to 2.2-dev |
- Make entropyHex parameter optional in documents.create() - Add generateEntropy() utility function that works in Node.js and browsers - Auto-generate entropy when not provided - Add comprehensive tests for entropy generation and auto-generation behavior
thephez
force-pushed
the
wasm-sdk-entropy-util
branch
from
3d69a24 to
cbb42ea
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/js-evo-sdk/src/documents/facade.ts (1)
75-80: Consider validating user-provided entropyHex format.The implementation correctly auto-generates entropy when not provided and maintains backward compatibility. However, when users do provide
entropyHex, there's no validation to ensure it's a valid 64-character hexadecimal string. Invalid input will be passed directly todocumentCreate, which may result in unclear error messages downstream.Consider adding validation when
entropyHexis provided:async create(args: { contractId: string; type: string; ownerId: string; data: unknown; entropyHex?: string; // Now optional - will auto-generate if not provided privateKeyWif: string; }): Promise<any> { const { contractId, type, ownerId, data, privateKeyWif } = args; // Auto-generate entropy if not provided const entropyHex = args.entropyHex ?? generateEntropy(); + // Validate entropy format if provided by user + if (args.entropyHex && !/^[0-9a-fA-F]{64}$/.test(entropyHex)) { + throw new Error('entropyHex must be a 64-character hexadecimal string'); + } const w = await this.sdk.getWasmSdkConnected(); return w.documentCreate(packages/js-evo-sdk/src/util.ts (1)
14-36: Remove dead code branches fromgenerateEntropy()to simplify the implementation.The first branch (lines 16-19) checking
'randomBytes' in globalThis.cryptois dead code and will never execute. In Node.js 15+,globalThis.cryptois the Web Crypto API, which does not have arandomBytesmethod. This method exists only in the Node.jscryptomodule.The second branch (lines 22-26) using
getRandomValuesalready handles both Node.js 15+ and browser environments correctly, so the dead code is unnecessary. The third branch (lines 29-33) with thewindow.cryptofallback is also redundant sinceglobalThisis universally supported in modern environments (Node.js 12+ and all modern browsers).Recommended simplification:
- Remove lines 16-19 (dead
randomBytescheck)- Remove lines 29-33 (redundant
window.cryptofallback)- Keep only the
globalThis.crypto.getRandomValuesbranch, which is sufficient for all supported environments
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/js-evo-sdk/src/documents/facade.ts(2 hunks)packages/js-evo-sdk/src/util.ts(1 hunks)packages/js-evo-sdk/tests/unit/facades/documents.spec.mjs(2 hunks)packages/js-evo-sdk/tests/unit/util.spec.mjs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/js-evo-sdk/tests/unit/facades/documents.spec.mjs
- packages/js-evo-sdk/tests/unit/util.spec.mjs
🧰 Additional context used
📓 Path-based instructions (1)
packages/**/**/*.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
packages/**/**/*.{js,ts,jsx,tsx}: Adhere to ESLint with Airbnb/TypeScript configs for JS/TS code
Use camelCase for JS/TS variables and functions
Use PascalCase for JS/TS classes
Prefer kebab-case filenames within JS packages
Files:
packages/js-evo-sdk/src/util.tspackages/js-evo-sdk/src/documents/facade.ts
🧠 Learnings (2)
📚 Learning: 2024-10-24T04:58:02.843Z
Learnt from: shumkov
Repo: dashpay/platform PR: 2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Applied to files:
packages/js-evo-sdk/src/util.ts
📚 Learning: 2025-07-28T20:00:08.502Z
Learnt from: QuantumExplorer
Repo: dashpay/platform PR: 2711
File: packages/wasm-sdk/AI_REFERENCE.md:771-783
Timestamp: 2025-07-28T20:00:08.502Z
Learning: In packages/wasm-sdk/AI_REFERENCE.md, the documentation correctly shows the actual SDK method signatures (including identityCreate and identityTopUp with their full parameter lists), which may differ from the UI inputs shown in fixed_definitions.json. The UI may collect fewer parameters from users while handling additional requirements internally.
Applied to files:
packages/js-evo-sdk/src/documents/facade.ts
🧬 Code graph analysis (2)
packages/js-evo-sdk/src/util.ts (1)
packages/wasm-sdk/tests/unit/derivation.spec.mjs (1)
b(140-140)
packages/js-evo-sdk/src/documents/facade.ts (1)
packages/js-evo-sdk/src/util.ts (1)
generateEntropy(14-36)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build JS packages / Build JS
- GitHub Check: Rust crates security audit
🔇 Additional comments (1)
packages/js-evo-sdk/src/documents/facade.ts (1)
1-1: LGTM: Import added correctly.The
generateEntropyimport is properly added alongside the existingasJsonStringimport.
|
@lklimek rebased and passing tests |
Issue being fixed or feature implemented
The evo-sdk's
documents.create()method required manual entropy generation, causing poor developer experience with cryptic error messages ("Cannot read properties of undefined (reading 'length')") and forcing developers to write boilerplate code for every document creation.What was done?
This PR adds automatic entropy generation to the
documents.create()method in js-evo-sdk, making the API simpler and more consistent with other SDK methods likedpns.registerName().Key changes:
entropyHexparameter optional indocuments.create()generateEntropy()utility function supporting both Node.js and browser environmentsHow Has This Been Tested?
tests/unit/facades/documents.spec.mjsto verify auto-generation behaviortests/unit/util.spec.mjswith comprehensive tests forgenerateEntropy()yarn buildBreaking Changes
None - this change is fully backward compatible. The
entropyHexparameter is now optional but still accepts values when provided.Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
New Features
Tests