.gitignore explicitly excludes package-lock.json (under the # deploy script dependencies (scripts/) section, alongside node_modules/). This means the exact resolved version of @stellar/stellar-sdk (pinned only loosely, ^16.0.1, in package.json) and its full transitive dependency tree is never pinned or reproducible across machines or over time — a stark asymmetry with the Rust side of this repo, which does commit Cargo.lock specifically so dependency resolution stays reproducible (and where the already-filed CI issue asks for --locked enforcement on top of that).
This isn't a hypothetical concern: scripts/deploy.mjs is what the README documents as literally having been used to deploy the currently-live testnet contracts. Without a committed lockfile, nobody can reproduce the exact @stellar/stellar-sdk version/behavior that deployment ran against. For an application/tooling directory (as opposed to a published library, where omitting a lockfile is conventional), committing package-lock.json is the standard practice for exactly this reproducibility reason. Consider removing it from .gitignore and committing the lockfile.
.gitignoreexplicitly excludespackage-lock.json(under the# deploy script dependencies (scripts/)section, alongsidenode_modules/). This means the exact resolved version of@stellar/stellar-sdk(pinned only loosely,^16.0.1, inpackage.json) and its full transitive dependency tree is never pinned or reproducible across machines or over time — a stark asymmetry with the Rust side of this repo, which does commitCargo.lockspecifically so dependency resolution stays reproducible (and where the already-filed CI issue asks for--lockedenforcement on top of that).This isn't a hypothetical concern:
scripts/deploy.mjsis what the README documents as literally having been used to deploy the currently-live testnet contracts. Without a committed lockfile, nobody can reproduce the exact@stellar/stellar-sdkversion/behavior that deployment ran against. For an application/tooling directory (as opposed to a published library, where omitting a lockfile is conventional), committingpackage-lock.jsonis the standard practice for exactly this reproducibility reason. Consider removing it from.gitignoreand committing the lockfile.