Trigger JavaScript CI on dependency manifest changes

[DanGould]

Problem

javascript.yml is the only workflow that compiles the tree for wasm32-unknown-unknown, and its pull_request trigger is filtered to payjoin-ffi/** (plus the flake, added in 1d8fe17).

That build is load-bearing for more than the bindings. ubrn.web.config.yaml builds with:

web:
    features: ["wasm_js"]
    defaultFeatures: false

which resolves through payjoin-ffi/Cargo.toml:14 (wasm_js = ["getrandom/js"]) to getrandom's browser backend. That backend is what supplies entropy to rand::thread_rng() in payjoin/src/core/receive/common/mod.rs:90 and :310 — the input and output shuffles. On wasm32-unknown-unknown there is no OS randomness syscall, so without it there is no entropy source at all.

The backend is contributed entirely by the dependency graph. A dependency bump can drop it without touching a single file under payjoin-ffi/, and the path filter means CI never builds wasm to find out.

The concrete case is close: bumping bitcoin 0.32 → 0.33 moves rand 0.8 → 0.9 and getrandom 0.2 → 0.3. In getrandom 0.3 the js feature is removed and replaced by a wasm_js feature plus a required RUSTFLAGS='--cfg getrandom_backend="wasm_js"'. A feature-only declaration silently stops being sufficient — and the name collision with our own wasm_js feature makes wasm_js = ["getrandom/wasm_js"] look correct while still being incomplete.

Fix

Add the manifests and the lockfile to the path filter, so any dependency change runs the wasm build:

- "**/Cargo.toml"
- Cargo.lock

This targets the dependency vector specifically. Source edits under payjoin/ cannot change which getrandom backend is selected; dependency changes necessarily touch Cargo.lock.

Why not a standalone cargo check job in rust.yml

That was the first thing I tried, and it does not work:

$ cargo check --target wasm32-unknown-unknown -p payjoin-ffi --no-default-features --features wasm_js
error[E0277]: `F` cannot be sent between threads safely
   --> uniffi_core-0.30.0/src/ffi/rustfuture/mod.rs:96:42

uniffi_core needs wasm-unstable-single-threaded on wasm32, and that feature is only applied to the ubrn-generated crate via wasm-manifest-patch.toml. Reproducing it outside ubrn means duplicating the patch, which is exactly the sort of thing that drifts. Widening the existing, working build's trigger is the cheaper and more honest fix.

Trade-off

Nearly every PR touches Cargo.lock, so in practice this runs the 2-OS JavaScript build on most PRs. If that's too much CI time, the narrower option is Cargo.lock alone (dependency resolution is what actually matters here) — happy to trim.

Conversely, if you'd rather also catch source-level wasm breakage — something like a std::time::Instant creeping into payjoin/ where web-time is needed — adding payjoin/** would cover that too, at more CI cost.

Testing

• Verified wasm_js → getrandom/js activation: enabling the feature pulls wasm-bindgen into the dependency graph, which only enters via getrandom's js backend.
• Verified the standalone cargo check failure above is real, not a toolchain artifact (run inside nix develop .#javascript, which provides the wasm32 target and the CC_wasm32_unknown_unknown / AR_wasm32_unknown_unknown that secp256k1-sys needs).
• YAML parses and the path list resolves as intended (yq '.on.pull_request.paths').
• Not verified locally: a green run of payjoin-ffi/javascript/contrib/test.sh. It fails in my environment at npm ci with yarn: command not found — the uniffi-bindgen-react-native git dependency's prepare script shells out to yarn, which the javascript devshell doesn't provide. GitHub's ubuntu/macos runners ship yarn preinstalled, so CI is unaffected, but it may be worth adding yarn to javascriptDevShell separately so the script is runnable under plain nix develop.

🤖 Generated with Claude Code