Skip to content

Dependency updates: rollup 4, eslint 10, mocha 11; ffjavascript commit-ref pin - #105

Open
OBrezhniev wants to merge 15 commits into
masterfrom
feature/deps-update
Open

Dependency updates: rollup 4, eslint 10, mocha 11; ffjavascript commit-ref pin#105
OBrezhniev wants to merge 15 commits into
masterfrom
feature/deps-update

Conversation

@OBrezhniev

Copy link
Copy Markdown
Member

Dependency updates: rollup 4, eslint 10, mocha 11; ffjavascript commit-ref pin

Summary

Companion to the snarkjs feature/memory-scoping PR (which pins this branch
by commit ref).

  • devDependencies — rollup 2 → 4, eslint 8 → 10 (.eslintrc.cjs migrated
    to flat eslint.config.mjs), mocha 10 → 11; bundle rebuilt, 3 tests pass.
  • Dropped an unused catch binding flagged by the new config.
  • ffjavascript pinned as a git+https://…#<commit> ref to the
    feature/msm-signed-buckets head this stack is developed against; local
    development uses an uncommitted file:../ override. Lockfile regenerated
    against the pin.

Landing order

After the ffjavascript PR lands; alternatively re-point the pin at the next
published ffjavascript version at merge time.

🤖 Generated with Claude Code

Migrates .eslintrc.cjs to flat eslint.config.mjs; drops an unused catch
binding. 3 tests pass; bundle rebuilds cleanly.
Points at the ffjavascript feature branch this stack is developed
against (resolves once that branch is pushed). For local development
keep an uncommitted file:../ffjavascript override in the working tree.
git+https installs anonymously (git+ssh needs SSH credentials).
@OBrezhniev

Copy link
Copy Markdown
Member Author

OBrezhniev and others added 9 commits July 4, 2026 20:17
js-yaml bumped in-range; serialize-javascript ^7.0.5 and diff ^8.0.3
overridden (mocha pins vulnerable ranges). npm audit clean.
…, and wrong-magic rejection

Corrupts the constraint section's bytes on disk and confirms
readR1csHeader (loadConstraints:false) still returns correct header
fields -- proving the lazy header-only read path genuinely never
touches that data, not just that it happens to work on well-formed
files. A follow-up loadConstraints:true call on the SAME corrupted
file confirms the corruption is real (it throws), so the header-only
success isn't a false negative.

Also covers rejection of a file with the wrong magic string, which had
no coverage.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant