Lock NPM Packages

[mattheworris]

Goal

The goal of this PR is update npm package dependencies.

Closes #2595

Discussion

• I have confirmed the changed versions match the previous resolved versions from the lock file.

Checklist

• Updated Pallet Readme?
• Updated js/api-augment for Custom RPC APIs?
• Design doc(s) updated?
• Unit Tests added?
• e2e Tests added?
• Benchmarks added?
• Spec version incremented?

[Copilot]

Pull Request Overview

This PR removes semver caret (^) and tilde (~) prefixes from NPM package dependencies to lock them to exact versions, preventing automatic minor and patch version updates during installation.

Key changes:

• Remove caret prefixes from package dependencies to enforce exact version pinning
• Update some packages to newer exact versions (e.g., @polkadot/api from 16.4.3 to 16.4.6 in api-augment)
• Apply version locking consistently across all JavaScript packages in the repository

Reviewed Changes

Copilot reviewed 10 out of 14 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tools/state-copy/package.json	Lock @polkadot/api and @polkadot/keyring to exact versions
tools/genesis-data/package.json	Lock @polkadot/api to exact version
tools/eth-migration/package.json	Lock @polkadot/api and pg to exact versions
scripts/js/onboard/package.json	Lock @PolkaDot packages to exact versions
js/schemas/scripts/package.json	Lock @polkadot/api to exact version
js/schemas/package.json	Lock all dev dependencies to exact versions
js/recovery-sdk/package.json	Lock all dev and runtime dependencies to exact versions
js/ethereum-utils/package.json	Lock all dependencies and dev dependencies to exact versions
js/api-augment/package.json	Lock dependencies to exact versions and update some to newer versions
e2e/package.json	Lock all dependencies and dev dependencies to exact versions

Files not reviewed (3)

• js/ethereum-utils/package-lock.json: Language not supported
• js/recovery-sdk/package-lock.json: Language not supported
• js/schemas/package-lock.json: Language not supported

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[shannonwells]

I read more carefully through the shorter package-lock.json files, & skimmed the one for api-augment. Noting that we can't control the failure of dependencies to omit ^ and ~ in their package.json, so there are some upgrades in the package-lock file for api-augment. You said that you'd run the check for the other package.json, so I'm approving, assuming the other package-locks have no changes.

[mattheworris]

I read more carefully through the shorter package-lock.json files, & skimmed the one for api-augment. Noting that we can't control the failure of dependencies to omit ^ and ~ in their package.json, so there are some upgrades in the package-lock file for api-augment. You said that you'd run the check for the other package.json, so I'm approving, assuming the other package-locks have no changes.

Those indirect dependencies are frustrating. I worked mostly on api-augment and tried to keep everything as same as possible, but npm just doesn't have that much control so the api augment lock file has significant differences. None of them seemed material to a vulnerability. The other package dependencies were not as extensive and did not have as many changes.

[enddynayn]

Can you please explain why we are pinning these for the test? For tests, it may actually be more useful not to pin them, since allowing updates can give us early warning signs.

[JoeCap08055]

Have we compared the newly-pinned versions with what was previously in the lockfile to make sure there are no reversions in dependencies?

I don't think it's an important issue for some of our other repos that are actual apps, but since the packages under the js/* directories are packages that have been previously published, I don't think we want to publish a new package that reverts some dependencies to older versions than what we previously published.

Not as important an issue for the e2e tests, other scripts, etc, I think. Just our published packages.

[mattheworris]

Have we compared the newly-pinned versions with what was previously in the lockfile to make sure there are no reversions in dependencies?

I don't think it's an important issue for some of our other repos that are actual apps, but since the packages under the js/* directories are packages that have been previously published, I don't think we want to publish a new package that reverts some dependencies to older versions than what we previously published.

Not as important an issue for the e2e tests, other scripts, etc, I think. Just our published packages.

Yes, I confirmed that all pinned packages were the same as the last lock file. The indirect dependencies picked up a patch here and there. (Besides api-augment and ethereum-utils, the other lock file diffs are small).

[JoeCap08055]

🔒

[aramikm]

Looks good. We have to also check our github ci scripts to ensure we are usjng the same lock files maybe in another PR

[enddynayn]

Should we update the CI to use npm ci if not there already?

[mattheworris]

Should we update the CI to use npm ci if not there already?

Will address in #2605

[mattheworris]

Looks good. We have to also check our github ci scripts to ensure we are usjng the same lock files maybe in another PR

Will address in #2605