feat: upgrade starknet peerDependency #347
Conversation
WalkthroughThe pull request introduces a comprehensive update to dependency management across multiple packages in the Dojo.js project. The primary change involves modifying package.json files to use a catalog-based versioning approach for the Changes
Assessment against linked issues
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (5)
pnpm-workspace.yaml (1)
4-7: Validate workspace-wide dependency resolutionThe new catalog section in pnpm-workspace.yaml is correctly structured. However, ensure that all packages in the workspace can resolve these dependencies without conflicts.
Consider documenting the following in the project's README or contribution guidelines:
- The reason for using the catalog section
- How workspace packages should reference these dependencies
- Any potential gotchas during dependency resolution
packages/state/package.json (1)
get-starknet-coreupgrade needed in@dojoengine/create-burnerpackageThe review comment is correct but pointed to the wrong package. The
get-starknet-coredependency is actually used in the@dojoengine/create-burnerpackage (currently at version ^3.3.3) and needs to be upgraded to ^4.0.0 as per PR objectives.
packages/create-burner/package.json: Updateget-starknet-corefrom^3.3.3to^4.0.0in dependencies🔗 Analysis chain
Line range hint
26-30: Address missing get-starknet-core upgradeThe PR objectives mention upgrading
get-starknet-coreto^4.0.0to resolve warnings, but this dependency is not present in the package.json. If this package is needed, it should be added as a peer dependency alongside starknet.Let's check if get-starknet-core is used in the codebase:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for get-starknet-core usage in the codebase rg "get-starknet-core" --type ts --type jsLength of output: 512
Script:
#!/bin/bash # Check if get-starknet-core is listed in create-burner's package.json cat packages/create-burner/package.jsonLength of output: 1501
packages/react/package.json (1)
Line range hint
43-43: Update get-starknet-core to resolve peer dependency warningsThe PR objectives mention upgrading get-starknet-core to ^4.0.0, but it's still at ^3.3.3. This older version is likely causing the peer dependency warnings with starknet@^6.11.0.
Apply this change to resolve the dependency warnings:
- "get-starknet-core": "^3.3.3", + "get-starknet-core": "^4.0.0",packages/create-burner/package.json (2)
Line range hint
44-44: Update get-starknet-core to resolve dependency warningsThe PR objectives mention upgrading get-starknet-core to ^4.0.0, but it's still at ^3.3.3. This needs to be updated to resolve the dependency warnings mentioned in issue #345.
Apply this change:
- "get-starknet-core": "^3.3.3", + "get-starknet-core": "^4.0.0",
Version mismatch detected between starknet dependencies
The package is using
get-starknet-core@^3.3.3which is compatible with the peer dependency requirement of@starknet-react/[email protected](requiresget-starknet-core@^3.2.0). However,@starknet-react/[email protected]has a peer dependency onstarknet@^5.25.0which is not listed in the dependencies. This missing peer dependency could cause runtime issues.
- Add
starknet@^5.25.0to the dependencies inpackages/create-burner/package.json🔗 Analysis chain
Line range hint
42-44: Verify compatibility between starknet-related dependenciesThere might be version conflicts between @starknet-react/[email protected], get-starknet-core, and the starknet peer dependency. Let's verify the compatibility requirements.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check peer dependencies of starknet-react/core echo "Checking @starknet-react/core peer dependencies..." curl -s https://registry.npmjs.org/@starknet-react/core/2.3.0 | jq '.peerDependencies' # Check peer dependencies of get-starknet-core echo "Checking get-starknet-core peer dependencies..." curl -s https://registry.npmjs.org/get-starknet-core/4.0.0 | jq '.peerDependencies'Length of output: 472
Script:
#!/bin/bash # Let's check the actual dependencies in package.json files echo "Checking dependencies in create-burner package.json..." cat packages/create-burner/package.json | jq '.dependencies' # Check if starknet or get-starknet-core is used in other package.json files echo "Searching for other package.json files with starknet dependencies..." fd package.json | xargs grep -l "starknet\|get-starknet"Length of output: 1186
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (7)
packages/core/package.json(1 hunks)packages/create-burner/package.json(1 hunks)packages/react/package.json(1 hunks)packages/sdk/package.json(1 hunks)packages/state/package.json(1 hunks)packages/utils/package.json(1 hunks)pnpm-workspace.yaml(1 hunks)
🔇 Additional comments (10)
pnpm-workspace.yaml (2)
5-7: Verify breaking changes in starknet v6.x.x
The upgrade from starknet@^5.18.0 to starknet@^6.11.0 represents a major version change that might introduce breaking changes. Please ensure all dependent packages are compatible with this version.
✅ Verification successful
Workspace dependencies are correctly aligned with catalog version
The verification shows that:
- All example projects use exact version
[email protected] - All core packages (
core,create-burner,react,sdk,state,utils) usestarknet: "catalog:*"as peer dependency, which correctly aligns with the catalog version
This confirms that the workspace configuration in pnpm-workspace.yaml is properly set up and all dependencies are consistently using the specified starknet version, either directly or through the catalog reference.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for potential breaking changes by examining package.json files
# in workspace packages for starknet dependencies
echo "Checking starknet dependencies in workspace packages..."
fd package.json -t f -E node_modules | xargs grep -l "starknet"
# Check for explicit starknet version constraints
echo "Checking explicit version constraints..."
fd package.json -t f -E node_modules | xargs grep -A 5 -B 5 '"starknet":'
Length of output: 12405
7-7: Verify get-starknet-core compatibility
The upgrade to get-starknet-core@^4.0.0 aligns with the PR objectives. However, we should verify that this version is compatible with starknet@^6.11.0.
packages/state/package.json (1)
24-24: Verify catalog configuration and version constraints
While moving to catalog:* provides flexibility, it might introduce version compatibility issues. The PR objective specifically mentions upgrading to starknet@^6.11.0, but using catalog:* removes this constraint.
Let's verify the catalog configuration and current resolution:
✅ Verification successful
Catalog configuration correctly enforces version constraints
The catalog:* reference in the package.json is properly constrained by the workspace-level catalog configuration in pnpm-workspace.yaml, which explicitly sets starknet: ^6.11.0. This matches the PR objective and ensures consistent versioning across the workspace.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check workspace configuration and resolved versions
cat pnpm-workspace.yaml
pnpm list starknet --json
Length of output: 254
packages/utils/package.json (2)
28-28: Consider using explicit version constraints
The PR objective mentions upgrading to starknet@^6.11.0, but we're using "catalog:*". While this might be intentional due to workspace configuration:
- Using
"catalog:*"without version constraints could lead to unexpected breaking changes - It's unclear how version resolution works with this syntax
✅ Verification successful
catalog:* is correctly configured with version constraint ^6.11.0 in workspace
The workspace configuration in pnpm-workspace.yaml explicitly sets starknet: ^6.11.0 under the catalog section. The catalog:* syntax in package.json files is a workspace feature that refers to this centralized version constraint, ensuring consistent versioning across all packages. This is actually a good practice as it maintains version consistency through a single source of truth.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check workspace configuration for catalog settings
cat pnpm-workspace.yaml
# Look for other catalog:* usage patterns
rg '"catalog:\*"' --type json
Length of output: 534
28-28: Verify compatibility with micro-starknet dependency
The package has a direct dependency on [email protected]. We should ensure this version is compatible with the new starknet peer dependency resolution.
✅ Verification successful
Let me verify the compatibility by checking the actual usage of starknet in the utils package.
Based on the results, I can now generate the final response:
Compatibility with micro-starknet is not a concern
The verification shows that:
micro-starknethas no peer dependencies, so it won't conflict with the starknet version- The utils package only uses basic imports from both packages:
poseidonHashManyfrom micro-starknetbyteArraytype from starknet
- These basic utilities are stable across starknet versions and unlikely to cause compatibility issues
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check micro-starknet's peer dependencies
curl -s https://registry.npmjs.org/micro-starknet/0.2.3 | jq '.peerDependencies'
# Search for any starknet imports or usage in the codebase
rg -l 'starknet' --type ts --type js
Length of output: 3656
Script:
#!/bin/bash
# Check how starknet is used in utils package
rg -A 5 'starknet' packages/utils/src/
# Check package.json of utils for all dependencies
cat packages/utils/package.json
Length of output: 1868
packages/core/package.json (1)
20-20: Verify the validity of "catalog:*" syntax
The use of "catalog:*" as a version specifier is non-standard. This appears to be related to a workspace configuration, but we should verify:
- That this syntax is valid and supported by pnpm
- How version resolution works with this syntax
- Whether this provides the intended version constraints
✅ Verification successful
catalog:* is a valid workspace-level version constraint mechanism
The verification confirms that:
- The
pnpm-workspace.yamldefines acatalogsection that specifiesstarknet: ^6.11.0 - Multiple packages in the workspace consistently use
"catalog:*"to inherit this version constraint - This approach ensures all packages use the same starknet version (^6.11.0) defined at the workspace level
This change aligns with the PR objectives by:
- Upgrading starknet to ^6.11.0 workspace-wide
- Using pnpm's workspace features to maintain version consistency
- Preventing version mismatches across packages
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check workspace configuration and catalog settings
cat pnpm-workspace.yaml
# Check if there are other packages using similar syntax
rg -g "package.json" '"catalog:\*"'
Length of output: 538
packages/react/package.json (1)
16-16: Verify the validity of "catalog:*" version specifier
The use of "catalog:*" as a version specifier is unusual. Standard semver patterns (e.g., "^6.11.0") would be more conventional and explicit about version requirements. Could you clarify the reasoning behind using the catalog versioning approach?
✅ Verification successful
"catalog:*" is a valid workspace-level version specifier
The use of "catalog:*" in package.json files is correct and intentional. The pnpm-workspace.yaml defines a catalog configuration that maps these references to specific versions:
- starknet: ^6.11.0
- get-starknet-core: ^4.0.0
This is a valid pnpm workspace feature that ensures consistent versioning across all packages in the monorepo.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if this versioning pattern is used elsewhere in the workspace
echo "Searching for other uses of catalog versioning..."
rg -l "catalog:\\*" --type json
Length of output: 314
Script:
#!/bin/bash
# Let's check the content of these package.json files to understand the pattern
for file in packages/*/package.json; do
echo "=== $file ==="
cat "$file" | jq -r '.peerDependencies.starknet, .dependencies.starknet | select(.)'
done
Length of output: 2403
Script:
#!/bin/bash
# Let's check the root package.json and any workspace configuration
echo "=== Root package.json ==="
cat package.json | jq -r '.packageManager, .workspaces'
echo -e "\n=== Looking for pnpm workspace config ==="
if [ -f "pnpm-workspace.yaml" ]; then
cat pnpm-workspace.yaml
fi
Length of output: 397
packages/create-burner/package.json (1)
17-17: Verify the unusual version specifier "catalog:*"
The change from a fixed version "6.11.0" to "catalog:*" is unusual. This pattern needs verification to ensure it's supported by your package manager and won't cause resolution issues.
✅ Verification successful
The "catalog:*" version specifier is valid and correctly configured
The version pattern "catalog:*" is a valid workspace-level configuration that references the centralized version management in pnpm-workspace.yaml. The workspace configuration shows:
- "starknet" is set to ^6.11.0
- This pattern is consistently used across multiple packages in the workspace
- The catalog configuration aligns with the PR's objective to upgrade starknet
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if this pattern is used elsewhere in the workspace
echo "Checking for other uses of catalog:* pattern..."
rg -l "catalog:\\*" --type json
# Check pnpm-workspace.yaml for catalog configuration
echo "Checking workspace configuration..."
cat pnpm-workspace.yaml
Length of output: 528
packages/sdk/package.json (2)
38-38:
Review the non-standard version syntax carefully
The change from a fixed version "6.11.0" to "catalog:*" introduces a non-standard version syntax. While this might be intentional for workspace-level version management, it differs from the PR objective of upgrading to ^6.11.0.
Consider using a standard semver range (e.g., ^6.11.0) unless there's a specific reason for using the catalog syntax. This would:
- Make version requirements more explicit
- Improve compatibility with standard package managers
- Better align with the PR objectives
✅ Verification successful
The catalog:* syntax is a valid workspace-level version management strategy
The verification shows that:
- The workspace configuration (
pnpm-workspace.yaml) explicitly defines catalog versions:starknet: ^6.11.0get-starknet-core: ^4.0.0
- This catalog syntax is consistently used across multiple packages in the workspace:
- utils, sdk, react, create-burner, state, and core packages
The catalog:* syntax in package.json correctly maps to the workspace-level version constraints defined in pnpm-workspace.yaml, which aligns perfectly with the PR objectives of upgrading to starknet@^6.11.0 and get-starknet-core@^4.0.0.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check how catalog dependencies are defined in the workspace
cat pnpm-workspace.yaml
# Check if other packages use similar catalog syntax
fd -e json -x grep -l "catalog:\*" {}
Length of output: 363
Line range hint 41-47: Verify dependency resolution with workspace packages
The package uses workspace dependencies for other @dojoengine packages. Ensure that the version resolution strategy is consistent across the workspace.
Consider documenting the version resolution strategy in the repository's README or contributing guidelines to help maintainers understand the catalog:* syntax and its implications.
✅ Verification successful
Let me gather more information about the workspace dependencies to verify the consistency.
This will help us verify if all internal package references use the same workspace dependency pattern consistently.
Workspace dependency resolution is consistent across packages
All workspace dependencies consistently use the workspace:* pattern across the packages. This includes:
- Internal package dependencies (e.g.,
@dojoengine/core,@dojoengine/state, etc.) - The peer dependencies for
starknetalso consistently usecatalog:* - No version conflicts or inconsistencies were found in the dependency resolution strategy
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check starknet dependency in other workspace packages
fd -t f "package.json" packages/ -x grep -l "starknet"
# Check for potential version conflicts
fd -t f "package.json" packages/ -x jq -r 'select(.peerDependencies.starknet) | "\(.name): \(.peerDependencies.starknet)"'
Length of output: 527
Script:
#!/bin/bash
# Check all workspace dependencies across packages
fd -t f "package.json" packages/ -x jq -r '
select(.dependencies != null) |
.name as $name |
.dependencies |
to_entries[] |
select(.value | startswith("workspace:")) |
[$name, .key, .value] |
@tsv
'
Length of output: 685
packages/core/package.json
Outdated
| @@ -17,7 +17,7 @@ | |||
| } | |||
| }, | |||
| "peerDependencies": { | |||
| "starknet": "6.11.0" | |||
| "starknet": "catalog:*" | |||
There was a problem hiding this comment.
💡 Codebase verification
Now I have enough information to provide the final response based on the issue details and package.json scans:
Inconsistency between implementation and requirements confirmed
The current implementation using "starknet": "catalog:*" across multiple packages doesn't align with the issue #345 requirements to upgrade to starknet@^6.11.0. Additionally:
get-starknet-coreis still at version^3.3.3in bothpackages/reactandpackages/create-burner, while issue [Feature]: Upgrade get-starknet-core dep #345 requires upgrading to^4.0.0- The peer dependency warnings mentioned in issue [Feature]: Upgrade get-starknet-core dep #345 will persist since the version requirements haven't been properly updated
🔗 Analysis chain
Alignment with PR objectives needs clarification
The PR objectives state that we want to upgrade to starknet@^6.11.0, but this change uses "catalog:*" instead. Additionally:
- The PR mentions updating
get-starknet-coreto^4.0.0, but no changes for this dependency are visible - It's unclear how this change resolves the peer dependency warnings mentioned in issue [Feature]: Upgrade get-starknet-core dep #345
Let me gather more information about the PR objectives and the issue #345 to better understand the context.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for get-starknet-core dependency across all package.json files
rg -g "package.json" "get-starknet-core"
# Look for any existing peer dependency warnings
rg -g "package.json" "peerDependencies" -A 5
Length of output: 2261
Script:
#!/bin/bash
# Check the PR description and issue #345
gh pr view --json title,body
gh issue view 345 --json title,body
# Check current starknet version in package-lock.json
rg -g "package-lock.json" '"starknet":' -A 2
Length of output: 931
| @@ -35,7 +35,7 @@ | |||
| "vitest": "^1.6.0" | |||
| }, | |||
| "peerDependencies": { | |||
| "starknet": "6.11.0" | |||
| "starknet": "catalog:*" | |||
| }, | |||
There was a problem hiding this comment.
Add missing get-starknet-core dependency
The PR objectives include upgrading both starknet and get-starknet-core, but get-starknet-core is not listed in the dependencies.
Add get-starknet-core as a peer dependency to properly address the warnings mentioned in issue #345:
"peerDependencies": {
"starknet": "catalog:*",
+ "get-starknet-core": "^4.0.0"
},Committable suggestion skipped: line range outside the PR's diff.
|
I would include |
MartianGreed
force-pushed
the
feat/upgrade-sn-deps
branch
from
8e7f255 to
c13aaca
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
examples/example-vite-kitchen-sink/package.json (1)
Line range hint
34-34: Update starknet dependency to use catalog reference.The starknet dependency is using a fixed version (6.11.0) while other packages use catalog:*.
Apply this change for consistency:
- "starknet": "6.11.0", + "starknet": "catalog:*",packages/create-burner/readme.md (3)
36-39: Document peer dependency requirements.Given that this PR updates peer dependencies for
starknetand adds new ones for@starknet-react/coreandget-starknet-core, please add a "Requirements" or "Prerequisites" section documenting these peer dependencies and their version requirements.Here's a suggested addition:
## Features: - Initialize and manage burner accounts. - Abstracts away intricacies related to creating, fetching, and setting active burner accounts. - Easily integrate with React apps using the provided hook. - Vanilla JS support. +## Prerequisites: + +This package has the following peer dependencies: +- `starknet`: ^6.11.0 +- `@starknet-react/core`: ^4.0.0 +- `get-starknet-core`: ^4.0.0
43-49: Fix markdown indentation for better readability.The unordered lists in the Table of Contents and API sections have inconsistent indentation. According to markdown best practices, nested list items should be indented by 2 spaces.
Apply these formatting changes:
## Table of Contents - [Installation](#installation) - [Usage](#usage) - - [With React](#with-react) - - [Vanilla JavaScript](#vanilla-javascript) + - [With React](#with-react) + - [Vanilla JavaScript](#vanilla-javascript) - [API](#api) - [Contribute](#contribute) - [License](#license) ## API - **useBurner**: A React hook that provides functionalities like creating burners, selecting them, and more. - - `get(address: string)`: Get a burner account based on its address. - - `list()`: List all burners. - - `select(address: string)`: Set a burner as the active account. - - `create()`: Create a new burner. - - `account`: The active burner account. - - `isDeploying`: A boolean that indicates whether a burner is being deployed. - - `listConnectors()`: List all available connectors that can be used with Starknet React. + - `get(address: string)`: Get a burner account based on its address. + - `list()`: List all burners. + - `select(address: string)`: Set a burner as the active account. + - `create()`: Create a new burner. + - `account`: The active burner account. + - `isDeploying`: A boolean that indicates whether a burner is being deployed. + - `listConnectors()`: List all available connectors that can be used with Starknet React. - **BurnerManager**: A class for vanilla JS that offers methods to manage burner accounts. - - `init()`: Initializes the manager. - - `getActiveAccount()`: Retrieves the active burner account. - - `get(address: string)`: Get a burner account based on its address. - - `list()`: List all burners. - - `select(address: string)`: Set a burner as the active account. - - `create()`: Create a new burner. - - `account`: The active burner account. - - `isDeploying`: A boolean that indicates whether a burner is being deployed. + - `init()`: Initializes the manager. + - `getActiveAccount()`: Retrieves the active burner account. + - `get(address: string)`: Get a burner account based on its address. + - `list()`: List all burners. + - `select(address: string)`: Set a burner as the active account. + - `create()`: Create a new burner. + - `account`: The active burner account. + - `isDeploying`: A boolean that indicates whether a burner is being deployed.Also applies to: 95-111
🧰 Tools
🪛 Markdownlint (0.35.0)
45-45: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
46-46: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
93-111: Enhance API documentation with return types and examples.The API documentation would benefit from including return types and usage examples for each method.
Consider enhancing the documentation with more details like this:
## API - **useBurner**: A React hook that provides functionalities like creating burners, selecting them, and more. - `get(address: string): Account | undefined`: Get a burner account based on its address. ```typescript const account = get("0x123..."); // Returns the account or undefined if not found ``` - `list(): Account[]`: List all burners. ```typescript const accounts = list(); // Returns array of all burner accounts ``` [Continue with similar enhancements for other methods...]🧰 Tools
🪛 Markdownlint (0.35.0)
95-95: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
96-96: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
97-97: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
98-98: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
99-99: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
100-100: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
101-101: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
104-104: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
105-105: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
106-106: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
107-107: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
108-108: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
109-109: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
110-110: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
111-111: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
🪛 LanguageTool
[uncategorized] ~95-~95: Loose punctuation mark.
Context: ... and more. -get(address: string): Get a burner account based on its addre...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~96-~96: Loose punctuation mark.
Context: ...unt based on its address. -list(): List all burners. - `select(address...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~97-~97: Loose punctuation mark.
Context: ...burners. -select(address: string): Set a burner as the active account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~98-~98: Loose punctuation mark.
Context: ... as the active account. -create(): Create a new burner. -account: T...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~99-~99: Loose punctuation mark.
Context: ...): Create a new burner. -account: The active burner account. -isDep...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~100-~100: Loose punctuation mark.
Context: ...tive burner account. -isDeploying: A boolean that indicates whether a burn...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~101-~101: Loose punctuation mark.
Context: ...being deployed. -listConnectors(): List all available connectors that can ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~104-~104: Loose punctuation mark.
Context: ...o manage burner accounts. -init(): Initializes the manager. - `getActi...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~105-~105: Loose punctuation mark.
Context: ... the manager. -getActiveAccount(): Retrieves the active burner account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~106-~106: Loose punctuation mark.
Context: ...er account. -get(address: string): Get a burner account based on its addre...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~107-~107: Loose punctuation mark.
Context: ...unt based on its address. -list(): List all burners. - `select(address...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~108-~108: Loose punctuation mark.
Context: ...burners. -select(address: string): Set a burner as the active account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~109-~109: Loose punctuation mark.
Context: ... as the active account. -create(): Create a new burner. -account: T...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~110-~110: Loose punctuation mark.
Context: ...): Create a new burner. -account: The active burner account. -isDep...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~111-~111: Loose punctuation mark.
Context: ...tive burner account. -isDeploying: A boolean that indicates whether a burn...(UNLIKELY_OPENING_PUNCTUATION)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (17)
.github/pull_request_template.md(1 hunks)examples/example-nodejs-bot/README.md(1 hunks)examples/example-vite-kitchen-sink/README.md(1 hunks)examples/example-vite-kitchen-sink/package.json(1 hunks)examples/example-vite-react-sdk/README.md(2 hunks)examples/example-vite-svelte-recs/README.md(1 hunks)packages/core/package.json(1 hunks)packages/create-burner/package.json(1 hunks)packages/create-burner/readme.md(3 hunks)packages/react/package.json(1 hunks)packages/sdk/package.json(1 hunks)packages/state/package.json(1 hunks)packages/utils/package.json(1 hunks)pnpm-workspace.yaml(1 hunks)readme.md(4 hunks)worlds/dojo-starter(1 hunks)worlds/onchain-dash(1 hunks)
✅ Files skipped from review due to trivial changes (8)
- worlds/onchain-dash
- worlds/dojo-starter
- examples/example-vite-svelte-recs/README.md
- examples/example-vite-kitchen-sink/README.md
- examples/example-nodejs-bot/README.md
- examples/example-vite-react-sdk/README.md
- readme.md
- .github/pull_request_template.md
🚧 Files skipped from review as they are similar to previous changes (5)
- packages/utils/package.json
- packages/state/package.json
- packages/sdk/package.json
- packages/core/package.json
- packages/create-burner/package.json
🧰 Additional context used
🪛 Markdownlint (0.35.0)
packages/create-burner/readme.md
45-45: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
46-46: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
95-95: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
96-96: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
97-97: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
98-98: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
99-99: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
100-100: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
101-101: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
104-104: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
105-105: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
106-106: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
107-107: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
108-108: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
109-109: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
110-110: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
111-111: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
🪛 LanguageTool
packages/create-burner/readme.md
[uncategorized] ~95-~95: Loose punctuation mark.
Context: ... and more. - get(address: string): Get a burner account based on its addre...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~96-~96: Loose punctuation mark.
Context: ...unt based on its address. - list(): List all burners. - `select(address...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~97-~97: Loose punctuation mark.
Context: ...burners. - select(address: string): Set a burner as the active account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~98-~98: Loose punctuation mark.
Context: ... as the active account. - create(): Create a new burner. - account: T...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~99-~99: Loose punctuation mark.
Context: ...): Create a new burner. - account: The active burner account. - isDep...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~100-~100: Loose punctuation mark.
Context: ...tive burner account. - isDeploying: A boolean that indicates whether a burn...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~101-~101: Loose punctuation mark.
Context: ...being deployed. - listConnectors(): List all available connectors that can ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~104-~104: Loose punctuation mark.
Context: ...o manage burner accounts. - init(): Initializes the manager. - `getActi...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~105-~105: Loose punctuation mark.
Context: ... the manager. - getActiveAccount(): Retrieves the active burner account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~106-~106: Loose punctuation mark.
Context: ...er account. - get(address: string): Get a burner account based on its addre...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~107-~107: Loose punctuation mark.
Context: ...unt based on its address. - list(): List all burners. - `select(address...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~108-~108: Loose punctuation mark.
Context: ...burners. - select(address: string): Set a burner as the active account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~109-~109: Loose punctuation mark.
Context: ... as the active account. - create(): Create a new burner. - account: T...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~110-~110: Loose punctuation mark.
Context: ...): Create a new burner. - account: The active burner account. - isDep...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~111-~111: Loose punctuation mark.
Context: ...tive burner account. - isDeploying: A boolean that indicates whether a burn...
(UNLIKELY_OPENING_PUNCTUATION)
🔇 Additional comments (3)
pnpm-workspace.yaml (1)
5-9: LGTM! Verify version compatibility.
The catalog section properly defines the upgraded versions as intended:
- starknet ^6.11.0
- get-starknet-core ^4.0.0
- @starknet-react/core ^3.0.0
- @starknet-react/chains ^2.9.0
Let's verify the compatibility between these versions:
✅ Verification successful
Let me try another verification approach to check the dependencies in the actual codebase:
Versions are compatible and correctly used across the codebase
The verification shows that:
- The specified versions in
pnpm-workspace.yamlcatalog are correctly used in the examples:[email protected]is consistently used across multiple packages@starknet-react/coreand@starknet-react/chainsare used with catalog versions inexample-vite-kitchen-sink
- No conflicting version requirements were found in dependencies or peer dependencies
- The packages are used together in working examples, indicating practical compatibility
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check peer dependencies compatibility between packages
# Get peer dependencies from npm registry
echo "Checking peer dependencies..."
for pkg in [email protected] [email protected] @starknet-react/[email protected] @starknet-react/[email protected]; do
echo "\nPeer dependencies for $pkg:"
curl -s "https://registry.npmjs.org/$pkg" | jq -r '.peerDependencies'
done
Length of output: 1300
Script:
#!/bin/bash
# Search for package.json files and their dependencies
echo "Searching for package.json files..."
fd package.json --type f --exec sh -c 'echo "\nFile: {}"; cat {} | jq -r ".dependencies, .devDependencies"'
Length of output: 15031
packages/react/package.json (1)
15-18: LGTM! Peer dependencies properly updated.
Good changes:
- Moving get-starknet-core to peerDependencies
- Using catalog:* to reference workspace-managed versions
Let's verify all required peer dependencies are declared:
examples/example-vite-kitchen-sink/package.json (1)
25-26: LGTM! @starknet-react dependencies properly updated.
The @starknet-react packages now correctly use catalog:* references.
MartianGreed
force-pushed
the
feat/upgrade-sn-deps
branch
from
c13aaca to
da05d56
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
packages/create-burner/readme.md (4)
36-39: Add version compatibility information to Features sectionGiven the recent upgrade of Starknet dependencies, consider adding information about version compatibility, particularly with
starknet@^6.11.0andget-starknet-core@^4.0.0.- Initialize and manage burner accounts. - Abstracts away intricacies related to creating, fetching, and setting active burner accounts. - Easily integrate with React apps using the provided hook. - Vanilla JS support. +- Compatible with Starknet ^6.11.0 and get-starknet-core ^4.0.0
43-49: Fix list indentation in Table of ContentsThe markdown linter indicates incorrect indentation for nested list items. The indentation should be 2 spaces instead of 4.
- [Installation](#installation) - [Usage](#usage) - - [With React](#with-react) - - [Vanilla JavaScript](#vanilla-javascript) + - [With React](#with-react) + - [Vanilla JavaScript](#vanilla-javascript) - [API](#api) - [Contribute](#contribute) - [License](#license)🧰 Tools
🪛 Markdownlint (0.35.0)
45-45: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
46-46: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
93-102: Enhance useBurner hook documentationThe
listConnectors()method needs more detailed documentation, especially regarding its relationship with Starknet React integration.- **useBurner**: A React hook that provides functionalities like creating burners, selecting them, and more. - - `listConnectors()`: List all available connectors that can be used with Starknet React. + - `listConnectors()`: Returns an array of available Starknet wallet connectors compatible with @starknet-react/core. Use this to integrate with existing wallet providers alongside burner accounts.🧰 Tools
🪛 Markdownlint (0.35.0)
95-95: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
96-96: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
97-97: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
98-98: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
99-99: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
100-100: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
101-101: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
🪛 LanguageTool
[uncategorized] ~95-~95: Loose punctuation mark.
Context: ... and more. -get(address: string): Get a burner account based on its addre...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~96-~96: Loose punctuation mark.
Context: ...unt based on its address. -list(): List all burners. - `select(address...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~97-~97: Loose punctuation mark.
Context: ...burners. -select(address: string): Set a burner as the active account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~98-~98: Loose punctuation mark.
Context: ... as the active account. -create(): Create a new burner. -account: T...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~99-~99: Loose punctuation mark.
Context: ...): Create a new burner. -account: The active burner account. -isDep...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~100-~100: Loose punctuation mark.
Context: ...tive burner account. -isDeploying: A boolean that indicates whether a burn...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~101-~101: Loose punctuation mark.
Context: ...being deployed. -listConnectors(): List all available connectors that can ...(UNLIKELY_OPENING_PUNCTUATION)
103-111: Fix indentation and enhance BurnerManager documentationThe markdown linter indicates incorrect indentation, and some method descriptions could be more detailed.
- **BurnerManager**: A class for vanilla JS that offers methods to manage burner accounts. - - `init()`: Initializes the manager. - - `getActiveAccount()`: Retrieves the active burner account. - - `get(address: string)`: Get a burner account based on its address. - - `list()`: List all burners. - - `select(address: string)`: Set a burner as the active account. - - `create()`: Create a new burner. - - `account`: The active burner account. - - `isDeploying`: A boolean that indicates whether a burner is being deployed. + - `init()`: Initializes the manager and sets up the necessary Starknet providers. + - `getActiveAccount()`: Retrieves the currently selected burner account. + - `get(address: string)`: Retrieves a specific burner account by its Starknet address. + - `list()`: Returns an array of all available burner accounts. + - `select(address: string)`: Sets a specific burner account as active by its address. + - `create()`: Creates and deploys a new burner account on Starknet. + - `account`: Reference to the currently active burner account. + - `isDeploying`: Boolean flag indicating whether a burner account deployment is in progress.🧰 Tools
🪛 Markdownlint (0.35.0)
104-104: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
105-105: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
106-106: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
107-107: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
108-108: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
109-109: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
110-110: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
111-111: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
🪛 LanguageTool
[uncategorized] ~104-~104: Loose punctuation mark.
Context: ...o manage burner accounts. -init(): Initializes the manager. - `getActi...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~105-~105: Loose punctuation mark.
Context: ... the manager. -getActiveAccount(): Retrieves the active burner account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~106-~106: Loose punctuation mark.
Context: ...er account. -get(address: string): Get a burner account based on its addre...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~107-~107: Loose punctuation mark.
Context: ...unt based on its address. -list(): List all burners. - `select(address...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~108-~108: Loose punctuation mark.
Context: ...burners. -select(address: string): Set a burner as the active account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~109-~109: Loose punctuation mark.
Context: ... as the active account. -create(): Create a new burner. -account: T...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~110-~110: Loose punctuation mark.
Context: ...): Create a new burner. -account: The active burner account. -isDep...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~111-~111: Loose punctuation mark.
Context: ...tive burner account. -isDeploying: A boolean that indicates whether a burn...(UNLIKELY_OPENING_PUNCTUATION)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (17)
.github/pull_request_template.md(1 hunks)examples/example-nodejs-bot/README.md(1 hunks)examples/example-vite-kitchen-sink/README.md(1 hunks)examples/example-vite-kitchen-sink/package.json(1 hunks)examples/example-vite-react-sdk/README.md(2 hunks)examples/example-vite-svelte-recs/README.md(1 hunks)packages/core/package.json(1 hunks)packages/create-burner/package.json(1 hunks)packages/create-burner/readme.md(3 hunks)packages/react/package.json(1 hunks)packages/sdk/package.json(1 hunks)packages/state/package.json(1 hunks)packages/utils/package.json(1 hunks)pnpm-workspace.yaml(1 hunks)readme.md(4 hunks)worlds/dojo-starter(1 hunks)worlds/onchain-dash(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (15)
- worlds/onchain-dash
- examples/example-vite-kitchen-sink/README.md
- readme.md
- examples/example-vite-react-sdk/README.md
- examples/example-nodejs-bot/README.md
- packages/core/package.json
- .github/pull_request_template.md
- packages/sdk/package.json
- pnpm-workspace.yaml
- worlds/dojo-starter
- packages/utils/package.json
- packages/react/package.json
- packages/state/package.json
- packages/create-burner/package.json
- examples/example-vite-kitchen-sink/package.json
🧰 Additional context used
🪛 LanguageTool
examples/example-vite-svelte-recs/README.md
[uncategorized] ~17-~17: Possible missing comma found.
Context: ...elteKit?** - It brings its own routing solution which might not be preferable for some ...
(AI_HYDRA_LEO_MISSING_COMMA)
packages/create-burner/readme.md
[uncategorized] ~95-~95: Loose punctuation mark.
Context: ... and more. - get(address: string): Get a burner account based on its addre...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~96-~96: Loose punctuation mark.
Context: ...unt based on its address. - list(): List all burners. - `select(address...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~97-~97: Loose punctuation mark.
Context: ...burners. - select(address: string): Set a burner as the active account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~98-~98: Loose punctuation mark.
Context: ... as the active account. - create(): Create a new burner. - account: T...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~99-~99: Loose punctuation mark.
Context: ...): Create a new burner. - account: The active burner account. - isDep...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~100-~100: Loose punctuation mark.
Context: ...tive burner account. - isDeploying: A boolean that indicates whether a burn...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~101-~101: Loose punctuation mark.
Context: ...being deployed. - listConnectors(): List all available connectors that can ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~104-~104: Loose punctuation mark.
Context: ...o manage burner accounts. - init(): Initializes the manager. - `getActi...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~105-~105: Loose punctuation mark.
Context: ... the manager. - getActiveAccount(): Retrieves the active burner account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~106-~106: Loose punctuation mark.
Context: ...er account. - get(address: string): Get a burner account based on its addre...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~107-~107: Loose punctuation mark.
Context: ...unt based on its address. - list(): List all burners. - `select(address...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~108-~108: Loose punctuation mark.
Context: ...burners. - select(address: string): Set a burner as the active account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~109-~109: Loose punctuation mark.
Context: ... as the active account. - create(): Create a new burner. - account: T...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~110-~110: Loose punctuation mark.
Context: ...): Create a new burner. - account: The active burner account. - isDep...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~111-~111: Loose punctuation mark.
Context: ...tive burner account. - isDeploying: A boolean that indicates whether a burn...
(UNLIKELY_OPENING_PUNCTUATION)
🪛 Markdownlint (0.35.0)
packages/create-burner/readme.md
45-45: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
46-46: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
95-95: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
96-96: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
97-97: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
98-98: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
99-99: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
100-100: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
101-101: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
104-104: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
105-105: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
106-106: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
107-107: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
108-108: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
109-109: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
110-110: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
111-111: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
🔇 Additional comments (1)
examples/example-vite-svelte-recs/README.md (1)
17-18: LGTM! Improved formatting consistency.
The added spaces before bullet points enhance the visual structure and readability of the documentation.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~17-~17: Possible missing comma found.
Context: ...elteKit?** - It brings its own routing solution which might not be preferable for some ...
(AI_HYDRA_LEO_MISSING_COMMA)
MartianGreed
force-pushed
the
feat/upgrade-sn-deps
branch
3 times, most recently
from
9de42b5 to
eee1d72
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
examples/example-vite-kitchen-sink/README.md (1)
Line range hint
7-9: Document dependency version requirementsGiven that this PR updates Starknet-related dependencies, consider adding a note about the required versions in the installation section.
Add version information after the installation instructions:
```bash pnpm install
+> Note: This project requires
starknet@^6.11.0andget-starknet-core@^4.0.0or higher.<details> <summary>🧰 Tools</summary> <details> <summary>🪛 LanguageTool</summary> [uncategorized] ~48-~48: You might be missing the article “the” here. Context: ...` ### Notes - you main want to update `actions` contract address in `src/compon... (AI_EN_LECTOR_MISSING_DETERMINER_THE) </details> </details> </blockquote></details> <details> <summary>packages/create-burner/readme.md (2)</summary><blockquote> `43-49`: **Fix markdown list indentation.** The markdown linter indicates that the list indentation should be 2 spaces instead of 4 spaces for better consistency with markdown standards. Apply this formatting change: ```diff - [Installation](#installation) - [Usage](#usage) - - [With React](#with-react) - - [Vanilla JavaScript](#vanilla-javascript) - [API](#api) - [Contribute](#contribute) - [License](#license) + [Installation](#installation) + [Usage](#usage) + - [With React](#with-react) + - [Vanilla JavaScript](#vanilla-javascript) + [API](#api) + [Contribute](#contribute) + [License](#license)🧰 Tools
🪛 Markdownlint (0.35.0)
45-45: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
46-46: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
93-111: Fix markdown list indentation in API section.The markdown linter indicates that the list indentation should be 2 spaces instead of 4 spaces for better consistency.
Apply this formatting change:
- **useBurner**: A React hook that provides functionalities like creating burners, selecting them, and more. - - `get(address: string)`: Get a burner account based on its address. - - `list()`: List all burners. - - `select(address: string)`: Set a burner as the active account. - - `create()`: Create a new burner. - - `account`: The active burner account. - - `isDeploying`: A boolean that indicates whether a burner is being deployed. - - `listConnectors()`: List all available connectors that can be used with Starknet React. + **useBurner**: A React hook that provides functionalities like creating burners, selecting them, and more. + - `get(address: string)`: Get a burner account based on its address. + - `list()`: List all burners. + - `select(address: string)`: Set a burner as the active account. + - `create()`: Create a new burner. + - `account`: The active burner account. + - `isDeploying`: A boolean that indicates whether a burner is being deployed. + - `listConnectors()`: List all available connectors that can be used with Starknet React.🧰 Tools
🪛 LanguageTool
[uncategorized] ~95-~95: Loose punctuation mark.
Context: ... and more. -get(address: string): Get a burner account based on its addre...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~96-~96: Loose punctuation mark.
Context: ...unt based on its address. -list(): List all burners. - `select(address...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~97-~97: Loose punctuation mark.
Context: ...burners. -select(address: string): Set a burner as the active account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~98-~98: Loose punctuation mark.
Context: ... as the active account. -create(): Create a new burner. -account: T...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~99-~99: Loose punctuation mark.
Context: ...): Create a new burner. -account: The active burner account. -isDep...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~100-~100: Loose punctuation mark.
Context: ...tive burner account. -isDeploying: A boolean that indicates whether a burn...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~101-~101: Loose punctuation mark.
Context: ...being deployed. -listConnectors(): List all available connectors that can ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~104-~104: Loose punctuation mark.
Context: ...o manage burner accounts. -init(): Initializes the manager. - `getActi...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~105-~105: Loose punctuation mark.
Context: ... the manager. -getActiveAccount(): Retrieves the active burner account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~106-~106: Loose punctuation mark.
Context: ...er account. -get(address: string): Get a burner account based on its addre...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~107-~107: Loose punctuation mark.
Context: ...unt based on its address. -list(): List all burners. - `select(address...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~108-~108: Loose punctuation mark.
Context: ...burners. -select(address: string): Set a burner as the active account. ...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~109-~109: Loose punctuation mark.
Context: ... as the active account. -create(): Create a new burner. -account: T...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~110-~110: Loose punctuation mark.
Context: ...): Create a new burner. -account: The active burner account. -isDep...(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~111-~111: Loose punctuation mark.
Context: ...tive burner account. -isDeploying: A boolean that indicates whether a burn...(UNLIKELY_OPENING_PUNCTUATION)
🪛 Markdownlint (0.35.0)
95-95: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
96-96: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
97-97: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
98-98: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
99-99: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
100-100: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
101-101: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
104-104: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
105-105: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
106-106: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
107-107: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
108-108: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
109-109: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
110-110: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
111-111: Expected: 2; Actual: 4
Unordered list indentation(MD007, ul-indent)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (16)
.github/pull_request_template.md(1 hunks)examples/example-nodejs-bot/README.md(1 hunks)examples/example-vite-kitchen-sink/README.md(1 hunks)examples/example-vite-kitchen-sink/package.json(1 hunks)examples/example-vite-react-sdk/README.md(2 hunks)examples/example-vite-svelte-recs/README.md(1 hunks)packages/core/package.json(1 hunks)packages/create-burner/package.json(1 hunks)packages/create-burner/readme.md(3 hunks)packages/react/package.json(1 hunks)packages/sdk/package.json(1 hunks)packages/state/package.json(1 hunks)packages/utils/package.json(1 hunks)pnpm-workspace.yaml(1 hunks)readme.md(4 hunks)worlds/dojo-starter(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (14)
- .github/pull_request_template.md
- examples/example-vite-svelte-recs/README.md
- worlds/dojo-starter
- readme.md
- examples/example-vite-react-sdk/README.md
- examples/example-nodejs-bot/README.md
- packages/state/package.json
- packages/sdk/package.json
- packages/utils/package.json
- examples/example-vite-kitchen-sink/package.json
- packages/core/package.json
- pnpm-workspace.yaml
- packages/react/package.json
- packages/create-burner/package.json
🧰 Additional context used
🪛 LanguageTool
examples/example-vite-kitchen-sink/README.md
[uncategorized] ~48-~48: You might be missing the article “the” here.
Context: ... ### Notes - you main want to updateactionscontract address insrc/compon...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
packages/create-burner/readme.md
[uncategorized] ~95-~95: Loose punctuation mark.
Context: ... and more. - get(address: string): Get a burner account based on its addre...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~96-~96: Loose punctuation mark.
Context: ...unt based on its address. - list(): List all burners. - `select(address...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~97-~97: Loose punctuation mark.
Context: ...burners. - select(address: string): Set a burner as the active account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~98-~98: Loose punctuation mark.
Context: ... as the active account. - create(): Create a new burner. - account: T...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~99-~99: Loose punctuation mark.
Context: ...): Create a new burner. - account: The active burner account. - isDep...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~100-~100: Loose punctuation mark.
Context: ...tive burner account. - isDeploying: A boolean that indicates whether a burn...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~101-~101: Loose punctuation mark.
Context: ...being deployed. - listConnectors(): List all available connectors that can ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~104-~104: Loose punctuation mark.
Context: ...o manage burner accounts. - init(): Initializes the manager. - `getActi...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~105-~105: Loose punctuation mark.
Context: ... the manager. - getActiveAccount(): Retrieves the active burner account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~106-~106: Loose punctuation mark.
Context: ...er account. - get(address: string): Get a burner account based on its addre...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~107-~107: Loose punctuation mark.
Context: ...unt based on its address. - list(): List all burners. - `select(address...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~108-~108: Loose punctuation mark.
Context: ...burners. - select(address: string): Set a burner as the active account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~109-~109: Loose punctuation mark.
Context: ... as the active account. - create(): Create a new burner. - account: T...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~110-~110: Loose punctuation mark.
Context: ...): Create a new burner. - account: The active burner account. - isDep...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~111-~111: Loose punctuation mark.
Context: ...tive burner account. - isDeploying: A boolean that indicates whether a burn...
(UNLIKELY_OPENING_PUNCTUATION)
🪛 Markdownlint (0.35.0)
packages/create-burner/readme.md
45-45: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
46-46: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
95-95: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
96-96: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
97-97: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
98-98: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
99-99: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
100-100: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
101-101: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
104-104: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
105-105: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
106-106: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
107-107: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
108-108: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
109-109: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
110-110: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
111-111: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
🔇 Additional comments (2)
packages/create-burner/readme.md (2)
36-39: LGTM! Features section is clear and accurate.
The features section effectively communicates the package's capabilities.
93-111: Verify API documentation accuracy after dependency upgrades.
Given the upgrade of starknet and get-starknet-core dependencies, please verify that:
- All documented methods are still available and function as described
- The new
listConnectors()method's behavior is accurately documented - No new methods or parameters were introduced with the upgraded dependencies
✅ Verification successful
Let me generate another script to check the useBurner hook implementation since the previous output didn't show it, and also check for any connector-related functionality.
Let me check the complete implementation of the useBurner hook to verify all documented methods.
API documentation is accurate and complete
The API documentation in the README.md matches the actual implementation in the codebase. All documented methods (get, list, select, create, listConnectors) are available and their descriptions are accurate. The properties (account, isDeploying) are also correctly documented. The new listConnectors() method is properly implemented and its documentation accurately describes its functionality to list available connectors that can be used with Starknet React.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify API documentation matches implementation
# Check for any new exports or changes in method signatures
ast-grep --pattern 'export { $_ }' packages/create-burner/src/
ast-grep --pattern 'export class BurnerManager {
$$$
}'
ast-grep --pattern 'export function useBurner($$$) {
$$$
}'
Length of output: 34740
Script:
#!/bin/bash
# Search for useBurner hook and listConnectors implementation
rg -A 5 "export function useBurner" packages/create-burner/
rg -A 5 "listConnectors" packages/create-burner/
Length of output: 2603
Script:
#!/bin/bash
# Get the complete useBurner hook implementation
cat packages/create-burner/src/hooks/useBurner.ts
Length of output: 5780
🧰 Tools
🪛 LanguageTool
[uncategorized] ~95-~95: Loose punctuation mark.
Context: ... and more. - get(address: string): Get a burner account based on its addre...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~96-~96: Loose punctuation mark.
Context: ...unt based on its address. - list(): List all burners. - `select(address...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~97-~97: Loose punctuation mark.
Context: ...burners. - select(address: string): Set a burner as the active account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~98-~98: Loose punctuation mark.
Context: ... as the active account. - create(): Create a new burner. - account: T...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~99-~99: Loose punctuation mark.
Context: ...): Create a new burner. - account: The active burner account. - isDep...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~100-~100: Loose punctuation mark.
Context: ...tive burner account. - isDeploying: A boolean that indicates whether a burn...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~101-~101: Loose punctuation mark.
Context: ...being deployed. - listConnectors(): List all available connectors that can ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~104-~104: Loose punctuation mark.
Context: ...o manage burner accounts. - init(): Initializes the manager. - `getActi...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~105-~105: Loose punctuation mark.
Context: ... the manager. - getActiveAccount(): Retrieves the active burner account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~106-~106: Loose punctuation mark.
Context: ...er account. - get(address: string): Get a burner account based on its addre...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~107-~107: Loose punctuation mark.
Context: ...unt based on its address. - list(): List all burners. - `select(address...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~108-~108: Loose punctuation mark.
Context: ...burners. - select(address: string): Set a burner as the active account. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~109-~109: Loose punctuation mark.
Context: ... as the active account. - create(): Create a new burner. - account: T...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~110-~110: Loose punctuation mark.
Context: ...): Create a new burner. - account: The active burner account. - isDep...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~111-~111: Loose punctuation mark.
Context: ...tive burner account. - isDeploying: A boolean that indicates whether a burn...
(UNLIKELY_OPENING_PUNCTUATION)
🪛 Markdownlint (0.35.0)
95-95: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
96-96: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
97-97: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
98-98: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
99-99: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
100-100: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
101-101: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
104-104: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
105-105: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
106-106: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
107-107: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
108-108: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
109-109: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
110-110: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
111-111: Expected: 2; Actual: 4
Unordered list indentation
(MD007, ul-indent)
| @@ -45,5 +45,5 @@ sozo migrate apply | |||
|
|
|||
| ### Notes | |||
|
|
|||
| - you main want to update `actions` contract address in `src/components/caller-counter.tsx` & `src/components/global-counter.tsx` which is hardcoded in those files. | |||
| - if you want to have braavos & argent wallet working, you need to deploy classes and deploy your wallet manually. | |||
| - you main want to update `actions` contract address in `src/components/caller-counter.tsx` & `src/components/global-counter.tsx` which is hardcoded in those files. | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix grammatical issues and enhance the guidance
The line contains grammatical issues and could benefit from more detailed guidance.
Apply this diff to fix the grammar:
- you main want to update `actions` contract address in `src/components/caller-counter.tsx` & `src/components/global-counter.tsx` which is hardcoded in those files.
+ you may want to update the `actions` contract address in `src/components/caller-counter.tsx` & `src/components/global-counter.tsx` which is hardcoded in those files.Additionally, consider adding more specific guidance about:
- Where to find the new contract address
- The expected format of the address
- What happens if the address is not updated
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - you main want to update `actions` contract address in `src/components/caller-counter.tsx` & `src/components/global-counter.tsx` which is hardcoded in those files. | |
| - you may want to update the `actions` contract address in `src/components/caller-counter.tsx` & `src/components/global-counter.tsx` which is hardcoded in those files. |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~48-~48: You might be missing the article “the” here.
Context: ... ### Notes - you main want to updateactionscontract address insrc/compon...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
MartianGreed
force-pushed
the
feat/upgrade-sn-deps
branch
from
eee1d72 to
9c60112
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (3)
examples/example-vite-react-phaser-recs/package.json (1)
Line range hint
13-43: Consider adding recommended dependenciesBased on the PR objectives and comments:
- Add
get-starknet-core@^4.0.0as mentioned in the PR description- Consider adding
@starknet-react/coreas suggested in the PR commentsApply this diff to add the missing dependencies:
"dependencies": { + "get-starknet-core": "^4.0.0", + "@starknet-react/core": "^1.0.0", "starknet": "catalog:",Please verify the specific version of
@starknet-react/corethat is compatible with the updated starknet version.examples/example-vue-app-recs/package.json (1)
Line range hint
11-19: Add missing dependencies mentioned in PR objectivesThe PR objectives mention upgrading
get-starknet-coreto ^4.0.0, but it's not included in the dependencies. Additionally, consider adding@starknet-react/coreas suggested in the PR comments.Apply this diff to add the missing dependencies:
"@dojoengine/state": "workspace:*", "@dojoengine/torii-client": "workspace:*", "@dojoengine/utils": "workspace:*", "@latticexyz/utils": "^2.2.8", + "get-starknet-core": "^4.0.0", + "@starknet-react/core": "^1.0.0", "starknet": "catalog:",packages/predeployed-connector/src/index.ts (1)
Line range hint
47-63: Validate or document theoptionsfields.
The constructor relies onoptionsto provide necessary metadata (id, name, account). Consider validating these fields or documenting that they must be defined. This will help prevent runtime errors when fields are missing or invalid.
🧹 Nitpick comments (8)
examples/example-vite-react-sdk/package.json (1)
23-23: Comprehensive dependency update recommendationsThe changes consistently implement catalog-based versioning for
starknetacross all examples, which aligns with the PR objectives. To ensure a complete upgrade:
- Add
@starknet-react/coreto relevant React-based examples- Consider updating
get-starknet-coreto^4.0.0as mentioned in PR objectives- Verify that the catalog version (
^6.11.0) is compatible with all example configurationsConsider adding a root-level
.npmrcor updatingpnpm-workspace.yamlto enforce consistent dependency resolution across all examples.Also applies to: 29-29, 27-27
examples/example-vite-react-threejs-recs/package.json (1)
Line range hint
34-35: Recommendations for comprehensive dependency upgradeBased on the PR objectives and the implemented changes, consider the following recommendations:
- As suggested by @rsodre, ensure
@starknet-react/coreis consistently upgraded across all packages- Document the catalog version constraints in the repository's README or contribution guidelines
- Consider adding a package.json script to validate version consistency across workspace
Would you like me to:
- Generate a validation script for checking version consistency?
- Create a documentation PR for the catalog versioning approach?
Also applies to: 49-49
packages/predeployed-connector/src/index.ts (6)
47-47: Avoid using @ts-ignore unless strictly necessary.
Leaving@ts-ignorein production code can hide legitimate issues and complicate debugging. If this override is truly needed, consider adding a comment explaining why.
Line range hint
64-68: Simplify theready()method.
Instead of creating a new Promise, returningPromise.resolve(!!this.options.account)may be more concise and avoids unnecessary promise construction.- ready(): Promise<boolean> { - return new Promise((resolve) => { - resolve(!!this.options.account); - }); - } + ready(): Promise<boolean> { + return Promise.resolve(!!this.options.account); + }
Line range hint
69-72: Implement thedisconnect()method or provide a safe fallback.
Currently, it always throws an error. Providing a minimal implementation will help avoid unexpected crashes if other parts of the code calldisconnect().
Line range hint
82-86: Check forgetChainIdavailability with strong typing.
Relying on@ts-ignorecan lead to runtime issues ifAccountInterfaceever changes. Consider updating type definitions forAccountInterfacewith agetChainIdmethod to remove the need for@ts-ignore.
Line range hint
102-226: Consider factoring out unimplemented RPC calls or providing partial support.
Severalwallet_*methods throw a generic error. Improving these stubs or removing them if they are not planned for implementation will reduce confusion for maintainers.
Line range hint
102-226: Check error handling for asynchronous calls.
Some unimplemented features throw exceptions, but others such asthis.account.executerely on upstream behavior. Consider wrapping these calls with try/catch to surface more descriptive errors for end users.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (22)
.github/pull_request_template.md(1 hunks)examples/example-vanillajs-phaser-recs/package.json(1 hunks)examples/example-vite-kitchen-sink/package.json(2 hunks)examples/example-vite-react-app-recs/package.json(1 hunks)examples/example-vite-react-phaser-recs/package.json(1 hunks)examples/example-vite-react-pwa-recs/package.json(1 hunks)examples/example-vite-react-sdk/package.json(1 hunks)examples/example-vite-react-sdk/tsconfig.app.tsbuildinfo(1 hunks)examples/example-vite-react-sdk/tsconfig.node.tsbuildinfo(1 hunks)examples/example-vite-react-threejs-recs/package.json(1 hunks)examples/example-vite-svelte-recs/package.json(1 hunks)examples/example-vue-app-recs/package.json(1 hunks)packages/core/package.json(1 hunks)packages/create-burner/package.json(1 hunks)packages/predeployed-connector/package.json(1 hunks)packages/predeployed-connector/src/index.ts(1 hunks)packages/react/package.json(1 hunks)packages/sdk/package.json(2 hunks)packages/state/package.json(1 hunks)packages/utils/package.json(1 hunks)pnpm-workspace.yaml(1 hunks)readme.md(4 hunks)
✅ Files skipped from review due to trivial changes (2)
- examples/example-vite-react-sdk/tsconfig.node.tsbuildinfo
- examples/example-vite-react-sdk/tsconfig.app.tsbuildinfo
🚧 Files skipped from review as they are similar to previous changes (10)
- packages/react/package.json
- packages/create-burner/package.json
- .github/pull_request_template.md
- packages/core/package.json
- packages/state/package.json
- readme.md
- packages/sdk/package.json
- packages/utils/package.json
- pnpm-workspace.yaml
- examples/example-vite-kitchen-sink/package.json
🔇 Additional comments (14)
examples/example-vite-react-phaser-recs/package.json (1)
38-38: Verify catalog versioning configuration
The change to "starknet": "catalog:" aligns with the broader dependency management strategy, but we should verify the catalog setup.
Run the following script to check the catalog configuration and current starknet version resolution:
✅ Verification successful
Catalog versioning is correctly configured
The catalog configuration in pnpm-workspace.yaml properly defines the version constraints:
starknet: ^6.11.0matches the suggested version- Additional related dependencies are also configured:
get-starknet-core: ^3.3.4@starknet-react/core: ^3.6.2@starknet-react/chains: ^3.1.0
The "catalog:" reference in the package.json will resolve to these centrally managed versions, ensuring consistency across the workspace.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check workspace configuration and catalog setup
echo "Checking pnpm-workspace.yaml for catalog configuration:"
cat pnpm-workspace.yaml
# Check if the suggested version constraint is properly set in the catalog
echo -e "\nSearching for starknet version constraints:"
rg -l "starknet.*6\.11\.0" --type yaml
Length of output: 545
examples/example-vite-react-pwa-recs/package.json (3)
33-33: Verify catalog configuration for starknet dependency
The change to "starknet": "catalog:" aligns with the new catalog-based versioning approach. However, we need to ensure the catalog is properly configured in the workspace.
Let's verify the catalog configuration and version constraints:
✅ Verification successful
Catalog configuration for starknet dependency is correctly set up
The catalog configuration in pnpm-workspace.yaml shows that:
starknetis properly configured with version^6.11.0- Related dependencies are also defined:
get-starknet-core: ^3.3.4@starknet-react/core: ^3.6.2@starknet-react/chains: ^3.1.0
The change to use "catalog:" in the package.json is correct and will resolve to the version specified in the workspace catalog.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if pnpm-workspace.yaml exists and contains the correct starknet version
if [ -f "pnpm-workspace.yaml" ]; then
echo "Checking starknet version in pnpm-workspace.yaml:"
cat pnpm-workspace.yaml | grep -A 5 "catalog:"
else
echo "Warning: pnpm-workspace.yaml not found"
fi
Length of output: 313
Line range hint 14-24: Verify workspace dependency compatibility
The project uses several workspace dependencies (@dojoengine/*). We should ensure these are compatible with the updated starknet version.
Let's check the workspace packages for starknet version compatibility:
✅ Verification successful
The previous results show that all packages use starknet: "catalog:" which is consistent, but we need to verify the actual versions of the workspace packages and any potential version constraints to ensure compatibility.
Workspace dependencies are compatible with consistent versioning
Based on the verification results:
- All workspace packages (@dojoengine/*) are consistently versioned at 1.0.7
- All packages use
starknet: "catalog:"consistently - The get-starknet-core dependency is consistently at version ^3.3.3 where used
The workspace dependencies are properly aligned and there are no version conflicts that would affect Starknet compatibility. The use of workspace dependencies (workspace:*) ensures that local versions are used consistently across the project.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check starknet dependency in workspace packages
echo "Checking starknet dependency in workspace packages:"
fd "package.json" -x grep -A 1 -B 1 '"starknet":' {} \;
# Check for potential version conflicts
echo "Checking for get-starknet-core dependency:"
fd "package.json" -x grep -A 1 -B 1 '"get-starknet-core":' {} \;
Length of output: 1965
Script:
#!/bin/bash
# Let's check the workspace dependencies versions in package.json files
echo "Checking workspace package versions:"
fd "package.json" -x grep -A 10 '"version":' {} \;
# Also check the starknet-react dependency
echo "Checking starknet-react dependency:"
fd "package.json" -x grep -A 1 -B 1 '"@starknet-react"' {} \;
# Let's also check if there are any explicit version constraints
echo "Checking workspace references:"
fd "package.json" -x grep -A 5 '"workspaces":' {} \;
Length of output: 7673
Line range hint 14-33: Consider adding @starknet-react/core dependency
As suggested in the PR comments by rsodre, consider adding @starknet-react/core to ensure complete compatibility with the updated starknet ecosystem.
Let's check for any existing usage or dependencies:
examples/example-vite-react-app-recs/package.json (3)
28-28: Verify peer dependency compatibility
The starknet version change might affect peer dependencies of other packages in the workspace (like @dojoengine/core, @dojoengine/react, etc.).
✅ Verification successful
All starknet dependencies are aligned with catalog: version
The verification shows that all packages in the workspace that have starknet as a dependency (either direct or peer) are using the same version catalog:. This includes:
- All @dojoengine packages (core, react, sdk, etc.) have peer dependency on starknet with version
catalog: - All example apps and packages have direct dependency on starknet with version
catalog:
Therefore, the version change is compatible across the workspace.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check peer dependencies in workspace packages
fd -t f "package.json" -x jq -r 'select(.peerDependencies != null) | select(.peerDependencies.starknet != null) | "\(.name): starknet \(.peerDependencies.starknet)"' {} \;
# Check for potential version conflicts
fd -t f "package.json" -x jq -r 'select(.dependencies.starknet != null or .devDependencies.starknet != null or .peerDependencies.starknet != null) | "\(.name): \(.dependencies.starknet // .devDependencies.starknet // .peerDependencies.starknet)"' {} \;
Length of output: 1129
28-28: Verify the catalog versioning strategy
The change from a fixed version to "catalog:" differs from the PR objective of upgrading to ^6.11.0. Please clarify:
- Is this part of a new workspace-level version management strategy?
- How does the catalog versioning ensure we get the intended
^6.11.0version?
✅ Verification successful
Catalog versioning is correctly implemented and aligned with PR objectives
The verification shows that there's a workspace-level catalog configuration that maps "catalog:" references to specific versions:
catalog:
starknet: ^6.11.0
get-starknet-core: ^3.3.4
"@starknet-react/core": ^3.6.2
"@starknet-react/chains": ^3.1.0
This configuration:
- Ensures consistent versioning across the workspace (found in 16 package.json files)
- Maps
"starknet": "catalog:"to^6.11.0, which aligns with the PR objective - Includes configurations for all suggested dependencies including
get-starknet-coreand@starknet-react/core
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there's a workspace-level catalog configuration
fd -t f "pnpm-workspace.yaml|package.json" -x cat {} \; | grep -A 5 "catalog"
# Check if there are other packages using catalog versioning
fd -t f "package.json" -x grep -l "catalog:" {} \;
Length of output: 4029
Line range hint 13-31: Consider adding suggested dependencies
Based on the PR comments and objectives:
@starknet-react/corewas suggested for inclusionget-starknet-core@^4.0.0was mentioned in the PR objectives but is not listed
Consider adding these dependencies if they're required for the application.
examples/example-vue-app-recs/package.json (2)
20-20: Verify catalog configuration and add version constraints
The change to use "catalog:" for starknet dependency aligns with the broader strategy, but there are a few concerns:
- No explicit version constraint might lead to unexpected updates
- Need to verify if the catalog is properly configured in workspace
✅ Verification successful
Catalog configuration is properly set up and standardized across workspace
The catalog configuration for the starknet dependency is correctly implemented:
- The workspace's
pnpm-workspace.yamldefines the version constraintstarknet: ^6.11.0in the catalog section - All packages consistently use
"catalog:"reference for the starknet dependency - The change aligns with the broader standardization effort across the workspace
The implementation ensures version consistency and addresses the PR objectives correctly through the centralized version management in the workspace catalog.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if catalog is configured in pnpm workspace
cat pnpm-workspace.yaml | grep -A 5 "catalog:"
# Check if there are any other files using starknet dependency
rg '"starknet":\s*"(?!catalog:)' -g 'package.json'
Length of output: 468
Script:
#!/bin/bash
# Check other package.json files for starknet dependency with fixed versions
rg --pcre2 '"starknet":\s*"[^c]' -g 'package.json'
# Check if there are any other catalog references
rg '"catalog:' -g 'package.json'
# Check root package.json for workspace configuration
cat package.json
Length of output: 2398
Line range hint 1-31: Verify dependency compatibility
The Vue.js version (^3.5.8) is quite recent. Please verify compatibility with the updated Starknet ecosystem dependencies.
✅ Verification successful
Let me analyze the Vue.js version compatibility across the project and its dependencies with these additional checks.
Vue.js version and tooling are compatible
The Vue.js version (^3.5.8) is being used with compatible tooling:
@vitejs/plugin-vuev5.1.4 supports Vue 3.xvue-tscv2.1.6 is designed for Vue 3.x TypeScript support- No compatibility warnings or issues were found in the documentation
- The only security vulnerability found affects Vue 2.x versions, not Vue 3.x
The Starknet ecosystem dependencies don't have direct Vue.js version requirements, and the example app appears to be the only Vue.js implementation in the codebase, making it self-contained.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any reported compatibility issues
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: NPM, package: "vue") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
}
}
}'
# Check if other example apps use the same Vue version
rg '"vue":\s*"\\^3.5.8"' -g 'package.json'
Length of output: 582
Script:
#!/bin/bash
# Check for Vue.js compatibility with other dependencies
rg '"vue":\s*"[^"]*"' -g 'package.json'
# Check for any Vue.js related issues or warnings in the codebase
rg -i 'vue.*compatibility|compatibility.*vue' -g '*.{md,txt}'
# Look for Vue.js version constraints in other configuration files
rg '"vue"' -g 'pnpm-lock.yaml'
# Check for Vue.js plugin versions and their compatibility
rg '@vitejs/plugin-vue|vue-tsc' -g 'package.json'
Length of output: 405
examples/example-vanillajs-phaser-recs/package.json (1)
27-27: Verify compatibility with @dojoengine packages
The change to use "starknet": "catalog:" aligns with the PR objectives. However, since this package depends on multiple @dojoengine workspace packages, we should verify compatibility across the dependency chain.
Run the following script to check for potential version conflicts:
✅ Verification successful
Updating to catalog: version is safe and compatible with the workspace dependencies
The verification results show that:
- The package uses workspace dependencies (
workspace:*) for all @dojoengine packages, which means they're locally linked and version-independent - Other Starknet-related dependencies in the workspace are pinned to specific versions:
micro-starknet: ^0.2.3get-starknet-core: ^3.3.3@starknet-io/types-js: ^0.7.10@starknet-react/core: 2.3.0
Since the package uses workspace dependencies for all @dojoengine packages, changing the starknet version to catalog: won't affect the internal compatibility. The other Starknet-related dependencies are independently versioned and don't rely on the main starknet package version.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for starknet version references across workspace packages
echo "Checking starknet version references in package.json files..."
fd --type f "package.json" | xargs rg "starknet.*[\^~]?[0-9]" -A 1 -B 1
# Check for potential breaking changes in dependent packages
echo "Checking @dojoengine dependencies..."
fd --type f "package.json" | xargs rg "@dojoengine.*workspace:\*" -A 1 -B 1
Length of output: 10247
examples/example-vite-svelte-recs/package.json (1)
29-29: Consider adding @starknet-react/core dependency
As suggested in the PR comments, consider adding @starknet-react/core to ensure all necessary starknet-related dependencies are updated consistently.
Run the following script to check for existing usage:
packages/predeployed-connector/package.json (1)
34-35: Verify catalog version constraints in workspace configuration
The change to use catalog: references for both @starknet-react/core and starknet aligns with the dependency upgrade objectives. However, we need to ensure the catalog versions are properly defined in the workspace configuration.
✅ Verification successful
Catalog version constraints are properly defined and consistent
The workspace configuration in pnpm-workspace.yaml correctly defines the catalog versions:
@starknet-react/core: ^3.6.2starknet: ^6.11.0
The usage of catalog: references in predeployed-connector package.json is consistent with other workspace packages, which all use the same pattern for starknet. Only predeployed-connector requires @starknet-react/core as a peer dependency, making its configuration unique but appropriate.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if catalog versions are defined in pnpm workspace config
if [ -f "pnpm-workspace.yaml" ]; then
echo "Checking catalog definitions in pnpm-workspace.yaml:"
cat pnpm-workspace.yaml
else
echo "Warning: pnpm-workspace.yaml not found"
fi
# Check for potential version conflicts in other workspace packages
fd -e json package.json | xargs cat | jq -r 'select(.peerDependencies != null) | select(.peerDependencies.starknet != null or .peerDependencies["@starknet-react/core"] != null) | "\(.name):\n starknet: \(.peerDependencies.starknet)\n @starknet-react/core: \(.peerDependencies["@starknet-react/core"])"'
Length of output: 1159
packages/predeployed-connector/src/index.ts (2)
Line range hint 78-81: Validate account presence.
Before returning this.options.account, consider throwing an error or returning null if account is undefined, to make the behavior clearer in client code.
Line range hint 227-267: Improve error handling for predeployedAccounts.
When provider.channel.getPredeployedAccounts() fails or returns unexpected data, the code may throw an unhandled exception. Consider adding a try/catch or verifying the response shape before mapping.
| @@ -20,7 +20,7 @@ | |||
| "immer": "^10.1.1", | |||
| "react": "^18.3.1", | |||
| "react-dom": "^18.3.1", | |||
| "starknet": "6.11.0", | |||
| "starknet": "catalog:", | |||
There was a problem hiding this comment.
💡 Codebase verification
React ecosystem compatibility is inconsistent across examples
The verification reveals inconsistencies in the React-Starknet integration:
- The example-vite-react-sdk package doesn't include
@starknet-react/coredespite being a React-based example - Other React examples like
example-vite-kitchen-sinkproperly use@starknet-react/corewith imports and StarknetProvider - There's a mix of versioning: some packages use
catalog:whilecreate-burneruses a fixed version "2.3.0"
To maintain consistency:
- Add
@starknet-react/core: "catalog:"to example-vite-react-sdk's dependencies - Consider adding basic Starknet React integration (StarknetProvider) similar to the kitchen-sink example
🔗 Analysis chain
Verify React ecosystem compatibility
The change to "starknet": "catalog:" is consistent with other examples. Since this is a React-based example:
- Consider adding
@starknet-react/coreas suggested in PR comments - Verify compatibility with React-specific dependencies
Run the following script to check compatibility:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check React dependencies compatibility
echo "Checking React-related dependencies..."
fd --type f "package.json" | xargs rg "\"react.*\": \".*\"" -A 1 -B 1
# Check for potential breaking changes in starknet React integration
echo "Checking starknet React integration..."
rg -t ts -t jsx -t tsx "useStarknet|StarknetProvider"
Length of output: 2772
Script:
#!/bin/bash
# Check for React-Starknet integration files and patterns
echo "Checking for React-Starknet integration..."
fd -e tsx -e ts | xargs rg "useStarknet|StarknetProvider"
# Check for @starknet-react/core dependency
echo "Checking for @starknet-react/core dependency..."
fd --type f "package.json" | xargs rg "@starknet-react/core"
# Look for React components using Starknet
echo "Looking for React components using Starknet..."
ast-grep --pattern 'import { $_ } from "@starknet-react/core"'
Length of output: 1607
| @@ -46,7 +46,7 @@ | |||
| "react": "^18.3.1", | |||
| "react-dom": "^18.3.1", | |||
| "rxjs": "^7.8.1", | |||
| "starknet": "6.11.0", | |||
| "starknet": "catalog:", | |||
There was a problem hiding this comment.
💡 Codebase verification
Version alignment needed for micro-starknet dependency
The verification reveals that:
micro-starknetversion^0.2.3is used in both@dojoengine/utilsandreact-threejspackages- The
utilspackage usesmicro-starknetfor itsposeidonHashManyfunction - There are no peer dependency requirements for
micro-starknet - The version is consistently pinned to
^0.2.3across the workspace
Since starknet is being updated to use catalog: reference, micro-starknet should also be aligned to use the same versioning strategy for consistency and to prevent potential compatibility issues.
packages/utils/package.json: Updatemicro-starknetto usecatalog:referenceexamples/example-vite-react-threejs-recs/package.json: Updatemicro-starknetto usecatalog:reference
🔗 Analysis chain
Verify compatibility with workspace and related packages
The change to use catalog: reference for starknet is consistent with the workspace-wide updates. However, there are several related packages that might need version alignment:
micro-starknetis still pinned to version 0.2.3- Multiple workspace dependencies that might depend on starknet
micro-starknet version mismatch found in workspace dependencies
The verification reveals that while starknet dependency is consistently using catalog: reference across all packages, there are two packages using a pinned version of micro-starknet:
react-threejspackage withmicro-starknet: "^0.2.3"@dojoengine/utilspackage withmicro-starknet: "^0.2.3"
Let's verify if there are any version constraints or peer dependencies that require this specific version:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check version compatibility across workspace
echo "Checking starknet-related dependencies across workspace:"
# Find all package.json files and extract starknet-related dependencies
fd -e json package.json | xargs cat | jq -r '
select(.dependencies != null or .peerDependencies != null) |
{
name,
starknet: (.dependencies.starknet // .peerDependencies.starknet),
"micro-starknet": .dependencies["micro-starknet"],
"get-starknet": (.dependencies["get-starknet"] // .peerDependencies["get-starknet"])
} | select(.starknet != null or .["micro-starknet"] != null or .["get-starknet"] != null)
'
Length of output: 2294
Script:
#!/bin/bash
# Check for micro-starknet version constraints in package.json files
fd -e json package.json | xargs cat | jq -r '
select(.peerDependencies != null) |
{
name,
"micro-starknet-peer": .peerDependencies["micro-starknet"]
} | select(.["micro-starknet-peer"] != null)
'
# Search for micro-starknet imports and usage
rg "micro-starknet" -A 2 -B 2
Length of output: 3360
|
I think |
Closes #345
Summary by CodeRabbit
Dependency Management
starknetacross multiple packages to use catalog referencesWorkspace Configuration
pnpm-workspace.yamlto include catalog dependenciesDocumentation
Chores