feat: upgrade to Starknet.js 10.0.2 - #529
Conversation
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis PR upgrades Starknet.js to v10.0.2 across the repository, migrating account-level API calls (waitForTransaction, getChainId, getTransactionReceipt, getNonceForAddress) to their provider-scoped equivalents. It also raises Node.js engine requirements to >=22 across packages and refactors create-dojo package.json generators into exported, testable helper functions. ChangesStarknet v10 migration and Node 22 baseline
Estimated code review effort: 2 (Simple) | ~15 minutes Sequence Diagram(s)sequenceDiagram
participant App
participant Account
participant Provider
App->>Account: execute(calls)
Account->>Provider: waitForTransaction(transaction_hash)
Provider-->>Account: receipt
Account-->>App: transaction confirmed
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (3)
packages/create-dojo/src/generators/client-app.ts (1)
47-53: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReplace
anywith a typed interface and add an explicit return type.
buildClientPackageJsonis exported and usesconst packageJson: any, violating two coding guidelines: avoidanyand maintain explicit return types for exported APIs. Theanytype means all downstream property assignments in the switch cases andadditionalDepsloop are unchecked.♻️ Proposed refactor: define a typed interface
+interface ClientPackageJson { + name: string; + version: string; + private: boolean; + type: string; + engines: { node: string }; + scripts: Record<string, string>; + overrides: Record<string, string>; + pnpm: { overrides: Record<string, string> }; + dependencies: Record<string, string>; + devDependencies: Record<string, string>; +} + -export function buildClientPackageJson( +export function buildClientPackageJson( config: ProjectConfig, versions: DojoVersions -): { +): ClientPackageJson { const { projectName, framework, additionalDeps } = config; - const packageJson: any = { + const packageJson: ClientPackageJson = { name: projectName,🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/create-dojo/src/generators/client-app.ts` around lines 47 - 53, Replace the untyped packageJson in buildClientPackageJson with a concrete interface or type that models the generated package.json shape, so the switch-case assignments and additionalDeps merges are type-checked instead of using any. Add an explicit return type to the exported buildClientPackageJson function, and keep the type aligned with the object built from projectName, framework, and versions so downstream consumers get a properly typed result.Source: Coding guidelines
packages/create-dojo/src/generators/worker-app.ts (1)
128-183: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueClean separation of concerns for testability.
Extracting
buildWorkerPackageJsonas a pure exported function while keeping the I/O increateWorkerPackageJsonis a solid refactor. The hardcodedstarknet: "10.0.2"across overrides, pnpm overrides, and dependencies is consistent with the PR objective.One minor note:
@types/nodeis set to^20.0.0(line 178) while the generatedenginesfield requires>=22(line 151). Consider bumping for type accuracy.💡 Optional: align `@types/node` with engine constraint
- "`@types/node`": "^20.0.0", + "`@types/node`": "^22.0.0",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/create-dojo/src/generators/worker-app.ts` around lines 128 - 183, The generated worker package metadata is inconsistent because buildWorkerPackageJson sets engines.node to >=22 while devDependencies still pin `@types/node` to a 20.x range. Update the `@types/node` entry in buildWorkerPackageJson to match the Node 22 engine requirement so the generated package.json stays type-accurate and aligned with the runtime constraint.example/package.json (1)
74-77: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider aligning
@types/nodewith the>=22engine requirement.
@types/nodeis pinned to^20.16.6(line 61) while the newenginesconstraint requires>=22. This means Node 22-specific APIs won't have type definitions, which could cause type errors or missed type safety for new APIs.💡 Optional: bump `@types/node`
- "`@types/node`": "^20.16.6", + "`@types/node`": "^22.0.0",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@example/package.json` around lines 74 - 77, Align the Node type definitions with the updated runtime requirement by updating the `@types/node` dependency in package.json to a version that matches Node 22 or newer. Keep the existing engines field as-is, and make sure the dependency version change is reflected alongside the current package metadata so TypeScript can correctly type Node 22 APIs.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@example/package.json`:
- Around line 74-77: Align the Node type definitions with the updated runtime
requirement by updating the `@types/node` dependency in package.json to a version
that matches Node 22 or newer. Keep the existing engines field as-is, and make
sure the dependency version change is reflected alongside the current package
metadata so TypeScript can correctly type Node 22 APIs.
In `@packages/create-dojo/src/generators/client-app.ts`:
- Around line 47-53: Replace the untyped packageJson in buildClientPackageJson
with a concrete interface or type that models the generated package.json shape,
so the switch-case assignments and additionalDeps merges are type-checked
instead of using any. Add an explicit return type to the exported
buildClientPackageJson function, and keep the type aligned with the object built
from projectName, framework, and versions so downstream consumers get a properly
typed result.
In `@packages/create-dojo/src/generators/worker-app.ts`:
- Around line 128-183: The generated worker package metadata is inconsistent
because buildWorkerPackageJson sets engines.node to >=22 while devDependencies
still pin `@types/node` to a 20.x range. Update the `@types/node` entry in
buildWorkerPackageJson to match the Node 22 engine requirement so the generated
package.json stays type-accurate and aligned with the runtime constraint.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 423fa835-6d8c-4bc7-a9b9-36632d4c2515
⛔ Files ignored due to path filters (1)
bun.lockis excluded by!**/*.lock
📒 Files selected for processing (26)
.changeset/starknet-v10-support.md.changeset/starknet-v9-support.mdCLAUDE.mdexample/core/dojo/createSystemCalls.tsexample/package.jsonpackage.jsonpackages/core/package.jsonpackages/create-burner/package.jsonpackages/create-burner/src/connectors/burner.tspackages/create-burner/src/manager/burnerManager.tspackages/create-burner/src/manager/prefundAccount.tspackages/create-burner/test/connectors/burner.test.tspackages/create-burner/test/manager/burnerManager.test.tspackages/create-burner/test/manager/prefundAccount.test.tspackages/create-dojo/package.jsonpackages/create-dojo/src/generators/client-app.tspackages/create-dojo/src/generators/package-json.test.tspackages/create-dojo/src/generators/worker-app.tspackages/grpc/package.jsonpackages/internal/package.jsonpackages/predeployed-connector/package.jsonpackages/predeployed-connector/src/index.tspackages/react/package.jsonpackages/sdk/package.jsonpackages/state/package.jsonpackages/utils/package.json
💤 Files with no reviewable changes (1)
- .changeset/starknet-v9-support.md
1 participant
Summary
account.provider.*and require Node.js 22 for affected packages and generated apps.Validation
bun install --frozen-lockfile, format, lint, tests, full build, release dry-run, and packed installs in npm, pnpm, and Bun all pass with one Starknet.js 10.0.2; the pre-existing@dojoengine/[email protected]Node entrypoint filename mismatch still prevents importing@dojoengine/sdk/nodein a clean consumer.Summary by CodeRabbit
New Features
Bug Fixes
Chores