Skip to content

Conversation

@notdanilo
Copy link
Contributor

@notdanilo notdanilo commented Oct 15, 2025

Status Type ⚠️ Core Change Issue
Ready Hotfix No None

Problem

bolt-cli was 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

    • Simplified CLI initialization by removing Solidity-specific options and paths.
    • Unified project creation to a single non-Solidity flow with consistent build, files, and templates.
    • Standardized test/template selection and workspace layout across languages.
    • Component-to-system dependency configuration now always applied.
  • Chores

    • Added/updated Solana-related dependencies and normalized dependency declarations.
    • Minor import and formatting cleanups with no user-facing behavior changes.

@coderabbitai
Copy link

coderabbitai bot commented Oct 15, 2025

Walkthrough

Updated workspace and crate Cargo dependencies (added solana-client and solana-system-interface; simplified solana-program spec), adjusted import paths, and refactored the bolt-cli init flow to remove Solidity-specific branches and the solidity parameter, standardizing on the non‑Solidity programs flow.

Changes

Cohort / File(s) Summary
Workspace root Cargo
Cargo.toml
Simplified solana-program dependency to a plain version string; added solana-client = "^2" and solana-system-interface = "^1". Minor formatting adjustments.
CLI crate Cargo
crates/bolt-cli/Cargo.toml
Added solana-client = "^2" and solana-system-interface = "^1" to crate dependencies; minor reordering/formatting.
Import updates
crates/bolt-cli/src/instructions.rs
Updated imports: RpcSendTransactionConfig now from solana_client::rpc_config; system_program now from solana_system_interface::program as system_program. No control-flow changes.
CLI init refactor
crates/bolt-cli/src/lib.rs
Removed Solidity-specific branches and the solidity: bool parameter from init; always follow non‑Solidity "programs" flow (create component/system, add component as system dependency, generate workspace/templates/tests).

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)
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
Title Check ❓ Inconclusive The pull request title "Making bolt-cli buildable again" is related to the main change in the PR, which is removing solang templates to fix the build issue caused by Anchor >= 0.32. However, the title is somewhat vague and generic—a teammate scanning commit history would understand that a build issue was fixed, but would not know the specific nature of the change (removal of solang support) without reading the full description. The emoji adds minor noise to an otherwise clear message. The title conveys the outcome but lacks specificity about what was actually changed.
✅ Passed checks (1 passed)
Check name Status Explanation
Description Check ✅ Passed The pull request description follows the template structure and includes all required core sections: the metadata table clearly marks this as a Ready Hotfix with no core change and no linked issue, the Problem section explains that bolt-cli became unbuildable due to Anchor >= 0.32 removing solang templates, and the Solution section states that solang templates were removed since they are not supported. The description is concise and provides sufficient context for understanding the change. Optional sections like Before & After Screenshots and Deploy Notes are not filled in, but these are non-critical for this type of hotfix.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/buildable-bolt-cli

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 06ba018 and 9c89cd4.

⛔ Files ignored due to path filters (1)
  • Cargo.lock is 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). (3)
  • GitHub Check: lint (clippy)
  • GitHub Check: lint (yarn)
  • GitHub Check: test
🔇 Additional comments (5)
crates/bolt-cli/Cargo.toml (1)

22-22: LGTM!

The workspace dependency additions for solana-client and solana-system-interface are correct and align with the import path changes in instructions.rs.

Also applies to: 34-35

crates/bolt-cli/src/instructions.rs (1)

8-9: LGTM!

The import path updates correctly reflect the new direct dependencies on solana-client and solana-system-interface, eliminating the need to access them transitively through anchor-client. No functional changes.

crates/bolt-cli/src/lib.rs (3)

289-313: LGTM!

The workspace configuration correctly registers component and system program IDs and adds the necessary workspace members. This standardizes the initialization flow to always include ECS components and systems.


368-371: LGTM!

The program, component, and system creation calls correctly follow the non-Solidity initialization flow, using rust_template::create_program, create_component, and create_system.


423-423: LGTM!

The test file generation correctly uses workspace-provided templates (templates::workspace::jest, templates::workspace::mocha, templates::workspace::ts_mocha) for all test frameworks, standardizing on the non-Solidity approach.

Also applies to: 426-426, 444-444


Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a 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 pattern

You 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

📥 Commits

Reviewing files that changed from the base of the PR and between f5186d9 and f7fe8a9.

⛔ Files ignored due to path filters (1)
  • Cargo.lock is 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 — LGTM

Jest/Mocha/TS variants wired correctly to the unified (non-Solidity) init flow.

Also applies to: 426-426, 445-445

Comment on lines +46 to +48
anchor-lang-idl = { version = "^0" }
solana-program = "^2"
solana-client = "^2"
solana-system-interface = "^1"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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*=' -C1

Length 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 }
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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*=' -C1

Length 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.

Comment on lines 368 to +372
// 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)?;

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

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.

@notdanilo notdanilo force-pushed the fix/buildable-bolt-cli branch from 06ba018 to 9c89cd4 Compare October 19, 2025 22:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants