we_manager/patches/steamworks-vote

steamworks.js vote support patch

steamworks.js (the Node wrapper this app uses for all Steam integration) doesn't bind ISteamUGC::SetUserItemVote/GetUserItemVote at all - confirmed by reading its actual source and the steamworks-rs Rust crate underneath it, not just its published .d.ts. Without this patch, we_manager casts votes via a raw FFI call to the flat SetUserItemVote C function directly (see voteOnItem() in src/main/services/steam.service.ts), which works for casting the vote but can't reliably read back whether Steam actually accepted it: steamworks.js's native addon owns Steam's manual-dispatch loop for this process and consumes every completed call's result as it ticks (~30/sec), including ones made via raw FFI from outside it - so there's no way to get real confirmation without going through steamworks.js's own dispatch ownership.

These patches add voteItem/getUserVote to a steamworks.js build the same way its own subscribe/unsubscribe/getUserItems are already implemented - registered through its existing internal async-call tracking (register_call_result), so they resolve correctly with no race. Once built and in place, we_manager detects and uses them automatically (see getPatchedVoteApi() in steam.service.ts) - the app keeps working without this patch too, just falling back to "trust the vote, sync later" instead of genuine confirmation.

What's in this directory

• steamworks-rs-ugc.patch - adds UGC::vote_up_item/UGC::user_item_vote to the steamworks Rust crate (Noxime/steamworks-rs), mirroring its existing subscribe_item/unsubscribe_item exactly.
• steamworks-js-workshop.patch - adds the corresponding voteItem/getUserVote napi-exposed async functions to steamworks.js's own src/api/workshop.rs, mirroring its existing subscribe/unsubscribe.
• steamworks-js-client-d-ts.patch - adds the matching TypeScript declarations to client.d.ts. Not strictly required to apply by hand: npm run build regenerates this file from the Rust #[napi] annotations automatically. Kept here for reference/as a fallback.

All three were generated against and verified (git apply --check) to apply cleanly to:

• ceifa/steamworks.js at its current main (the version this project's package.json pins, 0.4.0, predates these files slightly - a couple of unrelated functions were added upstream since - but the patch targets are unaffected).
• Noxime/steamworks-rs at the exact commit steamworks.js's own Cargo.toml pins (fbb79635b06b4feea8261e5ca3e8ea3ef42facf9).

Not yet compiled or run - this sandbox has no Rust toolchain, so the Rust code was written and verified by hand against the real upstream source (exact struct layouts/callback ids cross-checked against actual bindgen-generated output, not guessed) but never built. Do a real build + a real vote/like click before trusting it fully.

Building it (on your real machine, which has Steam installed and running - required by

steamworks.js's own build)

# 1. Clone both repos somewhere, e.g. alongside your other private forks
cd ~/projects/private
git clone https://github.com/Noxime/steamworks-rs
git clone https://github.com/ceifa/steamworks.js steamworksjs
cd steamworks-rs && git checkout fbb79635b06b4feea8261e5ca3e8ea3ef42facf9 && cd ..

# 2. Apply the patches
cd steamworks-rs && git apply /path/to/we_manager/patches/steamworks-vote/steamworks-rs-ugc.patch && cd ..
cd steamworksjs && git apply /path/to/we_manager/patches/steamworks-vote/steamworks-js-workshop.patch && cd ..

# 3. Point steamworks.js's build at your patched local steamworks-rs checkout instead of the
#    pinned git rev - add this to the END of steamworksjs/Cargo.toml:
cat >> steamworksjs/Cargo.toml <<'EOF'

[patch."https://github.com/Noxime/steamworks-rs/"]
steamworks = { path = "../steamworks-rs" }
EOF

# 4. Make sure you have: latest Node.js, Rust (rustup.rs), and Clang (needed by bindgen).
#    On Fedora/Nobara: sudo dnf install clang clang-devel
sudo dnf install clang clang-devel   # if not already installed

cd steamworksjs
npm install
npm run build:debug   # or `npm run build` for a release build - both work, release is smaller/faster

If it builds cleanly, steamworksjs/dist/linux64/steamworksjs.linux-x64-gnu.node and steamworksjs/client.d.ts are the freshly built, patched artifacts.

Wiring it into we_manager

Easiest: point we_manager's own package.json dependency at your local patched checkout instead of the npm-published package, so it survives future npm installs:

// we_manager/package.json
"dependencies": {
  "steamworks.js": "file:../steamworksjs"
}

Then from we_manager:

npm install
npm run build

(A quicker, non-persistent way to try it first: just copy the freshly built steamworksjs/dist/linux64/steamworksjs.linux-x64-gnu.node over we_manager/node_modules/steamworks.js/dist/linux64/steamworksjs.linux-x64-gnu.node directly - gets wiped out by the next npm install though, so switch to the file: dependency once you've confirmed it works.)

Verifying it actually took effect

getPatchedVoteApi() in steam.service.ts detects the new functions at runtime - no config flag needed. To confirm: like something in the app, then check the main process console log. There's no explicit "patched build detected" log line today, but you can add one temporarily, or just trust the behavior - once this is wired up, voteOnItemAndConfirm()'s patched branch runs, meaning a returned confirmed: true is now a real answer from Steam, not an optimistic guess, and checkUserVote(itemId) becomes available for a genuine on-demand "is this item already liked" check (not yet wired into any UI - a good next step, since once this works it can replace the whole crawl-based votedUpCache/getVotedUpItemIds() mechanism entirely for populating "liked" state, not just for confirming a fresh vote).