Skip to content

fix: repair fresh npm install + document that local forking is unsupported - #4

Open
Equious wants to merge 1 commit into
mainfrom
fix/registry-resolution-and-fork-docs
Open

fix: repair fresh npm install + document that local forking is unsupported#4
Equious wants to merge 1 commit into
mainfrom
fix/registry-resolution-and-fork-docs

Conversation

@Equious

@Equious Equious commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Two independent issues, both surfaced while validating the template against the restructured battlechain-lib.

1. Fresh npm install fails (lockfile points at a local tarball)

package-lock.json resolved @cyfrin/battlechain-lib-js to:

file:../battlechain-lib/packages/battlechain-lib-js/cyfrin-battlechain-lib-js-1.0.0.tgz

a path to a sibling monorepo checkout + an npm pack artifact from the author's machine. A fresh clone has neither, so npm install fails with ENOENT — the README's first instruction is dead on arrival. (package.json and .github/dependabot.yml are both registry-oriented, so this was a stale dev artifact in the lockfile, not the intended distribution mechanism.)

Fix: repoint that single lockfile entry to the npm registry, same version 1.0.0. Verified with npm ci (installs from registry, integrity validated). The 1.0.0 → 1.1.x bump is deliberately left to Dependabot: all published 1.1.x versions are <7 days old, inside this repo's 7-day cooldown, so adopting one now would violate that policy.

2. Local forking can't work on BattleChain — document it

BATTLECHAIN_FORK=1 / just node-fork produce a cryptic bcDeploy failure:

could not decode result data (value="0x", … "deployCreate(bytes)") BAD_DATA

Root cause: BattleChain is a ZKsync OS rollup, and its RPC can't serve what Hardhat/EDR forking needs:

  • historical state is pruned to ~the last 30 blocks (eth_getCode at the pinned fork block returns empty), and
  • eth_getProof is unsupported ("different storage layout than Ethereum").

So every forked contract reads back as empty code. No hardfork/chainType setting fixes it — it's a property of the chain. This PR replaces the misleading "forking makes contracts reachable" comment/README section with an accurate explanation and points users to the live-testnet flow (--network battlechain).

Diff

  • package-lock.json — 2 lines (local tarball → registry, same 1.0.0)
  • hardhat.config.ts — accurate comment on the BATTLECHAIN_FORK branch
  • README.md — rewrite "Local development" section + TOC anchor

🤖 Generated with Claude Code

…l forking is unsupported

The committed package-lock.json pinned @cyfrin/battlechain-lib-js to a local tarball
(file:../battlechain-lib/.../cyfrin-battlechain-lib-js-1.0.0.tgz) left over from local
development against a sibling monorepo checkout. A fresh clone has no such file, so
`npm install` fails with ENOENT — the README's first step is broken. Repoint that single
lockfile entry to the npm registry (same version 1.0.0). The 1.0.0 -> 1.1.x bump is left
to Dependabot under the repo's 7-day cooldown, since all newer versions are <7 days old.

Also correct the local-forking docs: BATTLECHAIN_FORK / `just node-fork` cannot work.
BattleChain is a ZKsync OS rollup whose RPC prunes historical state (~last 30 blocks) and
does not implement eth_getProof, so Hardhat/EDR cannot fork it (forked contracts read back
as empty code; bcDeploy fails with a BAD_DATA "0x" decode). Document why and point users to
the live testnet flow.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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