Fix stale @starknet-react/core imports and cairo test arity mismatch - #22
Merged
Conversation
app/page.tsx and app/vesu/page.tsx still imported from the old @starknet-react/core package name; the repo migrated to @starknet-start/react (or the local ~~/hooks/useAccount wrapper used by every other standalone useAccount consumer). test_set_greeting_no_allowance called set_greeting with 2 args instead of the 3 the contract requires, failing compilation (E2030) before tests could even run.
3 tasks
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
app/page.tsx:8importeduseBlockNumberfrom@starknet-react/core, the old package name (identical fix and byte-identical line to PR Fix stale @starknet-react/core import and cairo test arity mismatch #21 on step-2, verified character-for-character).app/vesu/page.tsx:11importeduseAccountfrom the same old package. Repointed to~~/hooks/useAccount— the local wrapper every other standaloneuseAccountconsumer in the codebase uses (ConnectedAddress.tsx,WriteOnlyFunctionForm.tsx,FaucetButton.tsx,useAutoConnect.ts,useTargetNetwork.ts,CustomConnectButton/index.tsx). This file only destructures.address, matching that convention (the two exceptions using the raw package,Header.tsxandNetworkOptions.tsx, do so because they import multiple hooks —useNetwork/useProvider/useSwitchChain— in one line).contracts/tests/test_contract.cairo:110— same arity fix as step-2 (byte-identical content, verified via diff).No refactors, no unrelated cleanup.
deployedContracts.tsuntouched (D1, out of scope).Proof (pasted command output)
Compile:
⏭️ Skipping compilation - all contracts are up to dateTest:
Compile-clean (E2030 gone) and full pass, including the 3
#[fork("SEPOLIA_LATEST")]tests.yarn format:check / scarb fmt --check: both clean, exit 0 — no reformatting needed.
next:check-types / yarn build: fail, both pre- and post-deploy, but due to a separate, pre-existing defect unrelated to this fix — a
symbol-typed index-signature error inContractUI.tsx/DebugContracts.tsx/useDeployedContractInfo.ts/contract.ts:56, traced to a contract-name union mismatch (likelyvStrk/mainnetForkmissing frompredeployedContracts.tsrelative toscaffold.config.ts'stargetNetworks: [chains.mainnetFork]). Verified viagit stashthat this failure is present identically with or without this PR's changes — it is not a regression from this fix and is out of this PR's scope (D2/D3 only).next dev (port 3002):
Both routes render — the actual proof the frontend works, independent of the strict-build type error above.
Test plan
yarn compileyarn test(5/5 pass)yarn format:check(clean)next devon port 3002,curl/→ 200,curl/vesu→ 200yarn next:check-types/yarn build— fails on a pre-existing, unrelated defect (see above), not introduced or fixed by this PR