build: make the workspace lockfile vendorable with --locked

[PastaPastaPasta]

Issue being fixed or feature implemented

cargo vendor --locked refuses the workspace on v4.2-dev:

found duplicate version of package `serde-wasm-bindgen v0.5.0` vendored from two sources:
    source 1: https://github.com/QuantumExplorer/serde-wasm-bindgen?branch=feat%2Fnot_human_readable#121d1f7f
    source 2: https://github.com/dashpay/serde-wasm-bindgen?branch=fix%2Fuint8array-to-bytes#0d3e1a8f

and, once that is resolved, the same for versioned-feature-core 1.0.0 (crates.io through grovedb-version, git through rs-platform-version). Offline build systems that vendor the workspace cannot get past this. Dash Core's depends packaging of the C++ embedding crate (the follow-up to this PR, see dashpay/dash#7512) is the first consumer that needs it.

What was done?

• wasm-dpp now pins serde-wasm-bindgen to the dashpay fork like wasm-sdk and wasm-dpp2 already do. That branch is the QuantumExplorer branch plus the Uint8Array fix and the current wasm-bindgen pin, so nothing changes for wasm-dpp beyond the source.
• rs-platform-version now depends on versioned-feature-core from crates.io instead of the dashpay git repo. The git pin was the repo's only substantive commit, published as 1.0.0 two days after the pin was written; the two trees differ only in cargo's Cargo.toml normalization on publish. grovedb-version already depended on the crates.io release, so this collapses two identical copies into one. (Earlier revision used a workspace [patch] table for this; the manifest edit is the direct fix and does not rely on a root-level override.)
• Cargo.lock loses the two duplicate entries.

Why the two source changes are safe

serde-wasm-bindgen. The dashpay branch is a descendant of the QuantumExplorer branch (git merge-base --is-ancestor confirms), adding two commits. Their source diff:

• is_human_readable becomes a per-deserializer flag with a from_value_json entry point. The default stays false, which is the value the QuantumExplorer branch hardcoded, and from_value (the only entry point wasm-dpp uses) still takes that default. The serializer side only gains a setter; Serializer::json_compatible() is unchanged.
• deserialize_any gains an as_bytes() arm so a Uint8Array/ArrayBuffer becomes visit_byte_buf. On the QuantumExplorer branch that input fell through every arm (typed arrays are not Array::is_array, and they carry Symbol.iterator, so the object arm rejects them) and returned an invalid_type error. The change turns an error into a value; no input that deserialized before deserializes differently now. Upstream serde-wasm-bindgen 0.6.5 has the same arm, so this brings the fork in line with upstream.
• wasm-dpp does not reach the changed arm: its JS→platform_value path stringifies through JSON (utils.rs::with_serde_to_platform_value), and its from_value targets are typed option structs and serde_json::Value maps, where a typed array errors both before and after (serde_json::Value has no bytes visitor).
• The wasm-bindgen pin the fork carries (=0.2.108) is the pin wasm-dpp already declares; the lockfile had 0.2.108 before and after.

Why they differed: wasm-dpp took the QuantumExplorer branch in 2023 (#809) for the non-human-readable mode; wasm-sdk moved from upstream 0.6.5 to the dashpay branch in 2025 (#2850) because it needed both that mode and the typed-array fix, and the new branch was cut from the old one. wasm-dpp was never moved along. Drift, not a deliberate split.

versioned-feature-core. rs-platform-version pinned the git repo on 2024-07-10 (#1938), the day the crate's only real commit landed; QuantumExplorer published 1.0.0 to crates.io on 2024-07-12. The git rev the lockfile held is that same tip commit. src/lib.rs is byte-identical between the two; the only difference is cargo's Cargo.toml normalization on publish. grovedb-version already depends on the crates.io release, so drive-abci was already compiling one copy from each source. Switching the manifest to the published release collapses them onto one with no source change.

How Has This Been Tested?

• cargo check --locked for platform-version, dash-platform-queries, dash-sdk, rs-sdk-ffi, drive-abci.
• cargo check --locked --target wasm32-unknown-unknown for wasm-dpp, wasm-sdk, wasm-dpp2.
• The tests-rs-workspace transport-free guards (hyper/rustls/tower absent from the verifier trees) still pass.
• cargo vendor --locked now succeeds (829 crates).
• Note on coverage: @dashevo/wasm-dpp's own JS tests are not in the PR matrix (nightly/workflow_dispatch only). Build JS compiled it and its consumers' suites ran on top of the built artifact; a workflow_dispatch run of the full matrix on this branch is linked below.

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

Summary by CodeRabbit

• Chores
  • Updated dependency sources and version resolution to improve build consistency.
  • Switched the WebAssembly serialization dependency to a DashPay-maintained repository and branch.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 8353e368-bc35-43da-8eb8-f1d5de73f991

📥 Commits

Reviewing files that changed from the base of the PR and between b45266b and 05927f9.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• Cargo.toml
• packages/wasm-dpp/Cargo.toml

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The changes update Cargo dependency sources. The workspace patches versioned-feature-core to crates.io version 1.0.0. The WASM package switches serde-wasm-bindgen to a DashPay branch.

Changes

Cargo dependency updates

Layer / File(s)	Summary
Dependency source alignment Cargo.toml, packages/wasm-dpp/Cargo.toml	The workspace pins versioned-feature-core to crates.io version 1.0.0. The WASM package uses DashPay’s fix/uint8array-to-bytes branch for serde-wasm-bindgen.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~2 minutes

Merge Risk: ⚪ Minimal · up to 05927

This change aligns Cargo dependency sources so the workspace lockfile can be vendored with --locked. The intended dependency resolutions are present, with no remaining merge-blocking risk identified.

Suggested reviewers: shumkov, lklimek

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: making the workspace lockfile vendorable with --locked.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch build/vendor-locked-single-source

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

🕓 Queued for automated review — 59th in line, estimated start in ~49 h (commit 1e8f252)
Estimated review time once started: ~1.6 h (two-phase automated review; median of recent runs).

• Request priority review — tick this box and the review moves to the front of the queue.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.33%. Comparing base (e037d42) to head (1e8f252).
⚠️ Report is 7 commits behind head on v4.2-dev.

Additional details and impacted files

@@             Coverage Diff              @@
##           v4.2-dev    #4631      +/-   ##
============================================
- Coverage     87.71%   87.33%   -0.38%     
============================================
  Files          2794     2795       +1     
  Lines        363048   365178    +2130     
============================================
+ Hits         318433   318933     +500     
- Misses        44615    46245    +1630     

Components	Coverage Δ
dpp	87.60% <ø> (-1.48%)	⬇️
drive	86.58% <ø> (+0.01%)	⬆️
drive-abci	89.85% <ø> (-0.08%)	⬇️
sdk	∅ <ø> (∅)
dapi-client	∅ <ø> (∅)
platform-version	∅ <ø> (∅)
platform-value	92.92% <ø> (ø)
platform-wallet	∅ <ø> (∅)
drive-proof-verifier	49.78% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[PastaPastaPasta]

Empirical check of the serde-wasm-bindgen source move, since "the dashpay branch is a superset" deserves evidence rather than a claim.

Setup. Built wasm-dpp twice with the same toolchain (Rust 1.92, wasm-bindgen 0.2.108): once at the base commit on the QuantumExplorer branch, once on this branch on the dashpay branch. Same JS build around each artifact.

1. The package's own mocha suite (excluded from the PR matrix, so run locally): 235 passing / 533 pending on both builds, with byte-identical lists of executed test titles.

2. Exhaustive input-kind sweep at the only surface where the two branches can differ: an untyped deserialization target (platform_value::Value), i.e. DataContractFactory.create(..., documents, ...), both at top level and nested inside a schema object. Inputs: Uint8Array, Buffer, ArrayBuffer, Int32Array, Float64Array, DataView, Map, Set, Date, null, undefined, bigint, number, string, bool, array, object, array-of-Uint8Array. Every outcome is identical between the builds except exactly four inputs: Uint8Array, Buffer, ArrayBuffer, and an array containing a Uint8Array. For those:

• old: error (invalid type: byte array, expected a valid platform value item; for ArrayBuffer, an empty map);
• new: nested, the value becomes Value::Bytes and survives to toObject() as a number array; top level, the usual "value is not a map" error.

So the complete delta is: a typed array placed where a JSON-schema fragment belongs used to be rejected at the boundary and is now decoded as bytes. Nothing that decoded before decodes differently.

3. Does the newly accepted input get anywhere? With validation on (createFromObject, skipValidation: false) the resulting contract is rejected by the meta-schema on both builds (Additional properties are not allowed ('weird' was unexpected)), exactly as a plain number array in the same place already was. createFromBuffer accepts both, on both builds, because the buffer path does not run schema validation (pre-existing, unrelated to this PR).

4. Serializer: no behavioural hunk; json_compatible() unchanged. The non-human-readable default is preserved (from_value still constructs with is_human_readable = false).

5. Same semantics already live: wasm-sdk and wasm-dpp2 have shipped on the dashpay branch since #2850 (Dec 2025), including untyped from_value::<Value> slots.

Full-matrix workflow_dispatch (runs the wasm-dpp suite in CI): https://github.com/dashpay/platform/actions/runs/34273784498

---

🤖 Posted autonomously by Claude on behalf of pasta.

[PastaPastaPasta]

I've confirmed this is safe; nothing changes really, there are only 2 changes;

1. changes source from 1.0.0 on GitHub to crates (matching other usage in repo)
2. changing from older QE fork to newer dashpay fork; confirmed no change in behavior, and proper