-
Notifications
You must be signed in to change notification settings - Fork 18
🩹 Making bolt-cli buildable again #211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
WalkthroughUpdated workspace and crate Cargo dependencies (added Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant U as User
participant CLI as bolt-cli:init
participant FS as Filesystem
participant WS as Workspace
participant T as Templates
participant P as Programs
participant PM as PackageManager
participant G as Git
U->>CLI: init(name, javascript, no_install, no_git, template, test_template, force)
rect rgba(200,230,255,0.35)
note right of CLI: Standardized non‑Solidity flow
CLI->>FS: create project dirs (programs, tests)
CLI->>P: create_component() and create_system()
CLI->>WS: write Cargo workspace, register component/system
CLI->>T: generate program and test templates
end
alt install unless no_install
CLI->>PM: install dependencies
end
alt git unless no_git
CLI->>G: git init
end
CLI-->>U: Result (project initialized)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: ASSERTIVE Plan: Pro ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
🧰 Additional context used🧬 Code graph analysis (1)crates/bolt-cli/src/lib.rs (2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
🔇 Additional comments (5)
Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
crates/bolt-cli/src/lib.rs (1)
357-366: Force cleanup: avoid create-then-remove patternYou create the dirs just to delete them. Prefer idempotent removal without pre-creation to reduce I/O and races.
- let programs_path = std::env::current_dir()? - .join("programs") - .join(&project_name); - fs::create_dir_all(&programs_path)?; - fs::remove_dir_all(&programs_path)?; + let programs_path = std::env::current_dir()?.join("programs").join(&project_name); + let _ = fs::remove_dir_all(&programs_path); - let programs_ecs_path = std::env::current_dir()? - .join("programs-ecs") - .join(&project_name); - fs::create_dir_all(&programs_ecs_path)?; - fs::remove_dir_all(&programs_ecs_path)?; + let programs_ecs_path = std::env::current_dir()?.join("programs-ecs").join(&project_name); + let _ = fs::remove_dir_all(&programs_ecs_path);Note: the ECS templates are under programs-ecs/components/* and programs-ecs/systems/*, not programs-ecs/<project_name>. Consider removing those specific dirs if they exist.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (4)
Cargo.toml(1 hunks)crates/bolt-cli/Cargo.toml(2 hunks)crates/bolt-cli/src/instructions.rs(1 hunks)crates/bolt-cli/src/lib.rs(5 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
crates/bolt-cli/src/lib.rs (2)
crates/bolt-cli/src/rust_template.rs (3)
create_system(31-44)create_component(15-28)create_program(47-61)crates/bolt-cli/src/templates/workspace/mod.rs (3)
jest(28-30)mocha(24-26)ts_mocha(32-34)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: setup
- GitHub Check: setup
🔇 Additional comments (3)
crates/bolt-cli/src/instructions.rs (1)
6-6: Good migration to Solana v2 paths
- system_program via solana-system-interface and RpcSendTransactionConfig via solana-client are correct for v2.
Also applies to: 8-8
crates/bolt-cli/src/lib.rs (2)
289-307: Init now standardizes non-Solidity workspace — LGTM
- Adds world/system/component deployments to Localnet and includes globs for programs and ECS dirs.
- Matches removal of Solidity paths in this PR’s intent.
Also applies to: 308-314
423-423: Workspace test templates — LGTMJest/Mocha/TS variants wired correctly to the unified (non-Solidity) init flow.
Also applies to: 426-426, 445-445
| anchor-lang-idl = { version = "^0" } | ||
| solana-program = "^2" | ||
| solana-client = "^2" | ||
| solana-system-interface = "^1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Workspace deps updated for Solana v2 — check Anchor version compatibility
Looks good. Ensure Anchor crates resolve to ≥0.30 (preferably ≥0.32) to match Solana v2 across the workspace.
Quick check for Anchor versions declared:
If needed, pin Anchor to 0.32.x in workspace.dependencies to avoid accidental downgrade.
🏁 Script executed:
#!/bin/bash
rg -nP --glob '**/Cargo.toml' 'anchor-(lang|cli|client|syn|lang-idl)\s*=' -C1Length of output: 1050
Pin Anchor workspace dependencies to ^0.32
In top-level Cargo.toml (lines 42–46), anchor-* crates use version = "^0" (resolves to <0.1.0), blocking Anchor v0.30+. Update them to version = "^0.32" (or >=0.30,<1.0.0) to ensure compatibility with Solana v2.
🤖 Prompt for AI Agents
In Cargo.toml around lines 46 to 49, the anchor-* workspace dependencies are
specified as version = "^0" which resolves to <0.1.0 and blocks Anchor v0.30+;
update those anchor-related entries to a pinned Anchor 0.32-compatible range
(e.g. version = "^0.32" or ">=0.30,<1.0.0") so the workspace uses Anchor v0.30+
compatible releases with Solana v2.
| [dependencies] | ||
| anchor-cli = { workspace = true } | ||
| anchor-client = { workspace = true } | ||
| solana-client = { workspace = true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Solana v2 dependencies added — verify workspace alignment
The additions look correct for Anchor ≥0.30. Please verify no crates still pin Solana v1 to avoid resolver conflicts.
Run to spot mismatched Solana versions in Cargo.toml files:
Also applies to: 34-35
🏁 Script executed:
#!/bin/bash
# List any Solana crates pinned to 1.x (should be none)
rg -nP -C1 --glob '**/Cargo.toml' '\bsolana-(program|client|system-interface)\b.*["'\'']?1\.' || true
# Show all declared Solana crate versions for quick visual check
rg -nP --glob '**/Cargo.toml' 'solana-(program|client|system-interface)\s*=' -C1Length of output: 550
solana-system-interface version mismatch — bump to v2
Root Cargo.toml still pins solana-system-interface = "^1" while solana-program and solana-client use v2. Update solana-system-interface to ^2 in Cargo.toml so workspace crates align.
🤖 Prompt for AI Agents
In crates/bolt-cli/Cargo.toml around line 22, the workspace root pins
solana-system-interface = "^1" while solana-program and solana-client require
v2; update the solana-system-interface entry to use "^2" so all workspace crates
depend on the same major version and then run cargo update / cargo check to
verify dependency resolution.
| // Build the program. | ||
| if solidity { | ||
| anchor_cli::solidity_template::create_program(&project_name)?; | ||
| } else { | ||
| create_system(system_name)?; | ||
| create_component(component_name)?; | ||
| rust_template::create_program(&project_name, template)?; | ||
|
|
||
| // Add the component as a dependency to the system | ||
| std::process::Command::new("cargo") | ||
| .arg("add") | ||
| .arg("--package") | ||
| .arg(system_name) | ||
| .arg("--path") | ||
| .arg(format!("programs-ecs/components/{}", component_name)) | ||
| .arg("--features") | ||
| .arg("cpi") | ||
| .stdout(std::process::Stdio::null()) | ||
| .stderr(std::process::Stdio::null()) | ||
| .spawn() | ||
| .map_err(|e| { | ||
| anyhow::format_err!( | ||
| "error adding component as dependency to the system: {}", | ||
| e.to_string() | ||
| ) | ||
| })?; | ||
| } | ||
| create_system(system_name)?; | ||
| create_component(component_name)?; | ||
| rust_template::create_program(&project_name, template)?; | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blocking: external command uses spawn() without waiting — results are nondeterministic
The cargo add command is started but not awaited, so dependency injection may silently fail or race with subsequent steps.
- std::process::Command::new("cargo")
+ let status = std::process::Command::new("cargo")
.arg("add")
.arg("--package")
.arg(system_name)
.arg("--path")
.arg(format!("programs-ecs/components/{}", component_name))
.arg("--features")
.arg("cpi")
.stdout(std::process::Stdio::null())
.stderr(std::process::Stdio::null())
- .spawn()
- .map_err(|e| {
- anyhow::format_err!(
- "error adding component as dependency to the system: {}",
- e.to_string()
- )
- })?;
+ .status()
+ .map_err(|e| anyhow::format_err!("failed to run cargo add: {}", e))?;
+ if !status.success() {
+ return Err(anyhow::format_err!(
+ "cargo add failed when adding component '{}' as dependency to system '{}'",
+ component_name,
+ system_name
+ ));
+ }Also apply the same fix to other Command::spawn() usages that must complete before proceeding (e.g., add_types_crate_dependency, and optionally the solana program dump step if the generated artifact is required immediately).
Also applies to: 373-390
🤖 Prompt for AI Agents
crates/bolt-cli/src/lib.rs around lines 368-372 (and also apply to 373-390):
external commands are launched with Command::spawn() and not awaited, causing
race conditions; change these to use Command::status() or Command::output() (or
call child.wait() / child.wait_with_output()) and check the exit status/error,
so the code blocks until the external process completes; apply the same change
in add_types_crate_dependency and any solana program dump invocation that must
finish before subsequent steps, and propagate or return errors when the child
process exits with a non-zero status.
06ba018 to
9c89cd4
Compare
Problem
bolt-cliwas no longer buildable with Anchor >= 0.32 because it removed solang templates.Solution
Remove solang templates since we don't support it.
Summary by CodeRabbit
Refactor
Chores