Pin next + eslint-config-next to 16.1.7 (CVE mitigation, closes #103)

[mert-kocoglu]

Closes #103

Summary

Pins next and eslint-config-next to exactly 16.1.7 in package.json so the resolver cannot fall back to a vulnerable 16.x patch version. The carets ^ are removed.

Acceptance criteria

• package.json specifies "next": "16.1.7" (exact, no caret)
• eslint-config-next updated to "16.1.7" (exact, no caret)
• package-lock.json regenerated — see "Lockfile note" below
• App builds via npm run build — needs CI with @tari-project npm-token
• Wrap/unwrap E2E in TU — needs maintainer-side test environment

Lockfile note

Local regeneration of package-lock.json requires npm install, which pulls @tari-project/wxtm-bridge-contracts@0.1.12 from a private registry. Without an @tari-project npm token, I can't regenerate the lockfile cleanly here. Two ways to close this:

1. CI on the PR (already authenticated to your private registry) regenerates and amends.
2. Add me as collaborator with read access to the private registry and I'll push the updated lockfile.

The mechanical pin in package.json is the substantive change; lockfile regen is a one-command follow-up.

[github-actions]

⚠️ This PR contains unsigned commits. To get your PR merged, please sign those commits (git rebase --exec 'git commit -S --amend --no-edit -n' @{upstream}) and force push them to this branch (git push --force-with-lease).

If you're new to commit signing, there are different ways to set it up:

Sign commits with gpg

Follow the steps below to set up commit signing with gpg:

1. Generate a GPG key
2. Add the GPG key to your GitHub account
3. Configure git to use your GPG key for commit signing

Sign commits with ssh-agent

Follow the steps below to set up commit signing with ssh-agent:

1. Generate an SSH key and add it to ssh-agent
2. Add the SSH key to your GitHub account
3. Configure git to use your SSH key for commit signing

Sign commits with 1Password

You can also sign commits using 1Password, which lets you sign commits with biometrics without the signing key leaving the local 1Password process.

Learn how to use 1Password to sign your commits.

[gemini-code-assist]

Code Review

This pull request updates the next and eslint-config-next dependencies in package.json. The reviewer identified that the specified version 16.1.7 is likely a typo for 15.1.7, as the former does not exist in the public registry and would cause installation failures.

[gemini-code-assist]

The version 16.1.7 for next is likely a typo for 15.1.7. Next.js is currently on major version 15, and 15.1.7 is the specific release containing the security fixes intended for this PR. This version does not exist in the public npm registry, which will cause installation failures unless a private registry with this specific version is configured. This discrepancy appears to have been inherited from the previous 16.1.1 entry.

Suggested change

	"next": "16.1.7",
	"next": "15.1.7",

[gemini-code-assist]

The version 16.1.7 for eslint-config-next is likely a typo for 15.1.7, matching the likely intended version for the next package. Using a version that does not exist in the public registry will prevent successful dependency installation.

Suggested change

	"eslint-config-next": "16.1.7",
	"eslint-config-next": "15.1.7",

[mert-kocoglu]

Thanks for the review @gemini-code-assist. Both next@16.1.7 and eslint-config-next@16.1.7 do exist on the public npm registry — Next.js shipped major version 16 in late 2025 and is currently on 16.2.5 (latest). The issue body (#103) explicitly specifies pinning to 16.1.7 as the patched release, and the original package.json here already had "next": "^16.1.1" so the major-version baseline was 16.

Verification:

• npm view next@16.1.7 version → 16.1.7
• npm view eslint-config-next@16.1.7 version → 16.1.7

No change needed. Closing the suggestion.

[gemini-code-assist]

Understood, thank you for the clarification and for verifying the package versions. Since the pinning to 16.1.7 is intentional to address the specific CVE mentioned in #103, the current approach is correct. I have noted your comments regarding the package-lock.json regeneration.