feat: add dashboard command to open app dashboard

[kfirstri]

Summary

Adds a new dashboard command that opens the app's dashboard page in the user's browser.

Changes

• Created src/cli/commands/project/dashboard.ts with the new command
• Registered the command in src/cli/index.ts
• Uses platform-specific commands for cross-platform browser opening
• Validates that BASE44_CLIENT_ID is configured
• Displays user-friendly messages

Resolves #80

Generated with Claude Code

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.0.11-pr.82.5adefb8

Prefer not to change any import paths? Install using npm alias so your code still imports base44:

npm i "base44@npm:@base44-preview/cli@0.0.11-pr.82.5adefb8"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.0.11-pr.82.5adefb8"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.0.11-pr.82.5adefb8
• 🔗 View this commit on GitHub

---

_{Preview published to npm registry — try new features instantly!}

[claude]

Code Review for PR #82 - Add dashboard command

Thank you for this contribution! The implementation is generally solid and follows the repository's patterns. Below is my detailed review:

✅ Strengths

1. Consistent with existing patterns: The command structure follows the same patterns as other commands (e.g., login, create)
2. Good error handling: Gracefully falls back to displaying the URL if browser opening fails
3. Cross-platform support: Handles macOS, Windows, and Linux
4. Proper validation: Checks for BASE44_CLIENT_ID before proceeding
5. User-friendly messages: Clear feedback at each step

🐛 Potential Issues

1. Security Concern: Shell Injection Risk (High Priority)

Location: src/cli/commands/project/dashboard.ts:37

await execa(openCommand, [dashboardUrl], { shell: true });

Issue: Using { shell: true } with user-controlled input (the URL) opens the door to potential command injection vulnerabilities. While dashboardUrl is constructed internally, it includes BASE44_CLIENT_ID from environment variables which could theoretically be manipulated.

Recommendation: Remove { shell: true } since you're already passing arguments as an array:

await execa(openCommand, [dashboardUrl]);

The array syntax already provides proper escaping, and shell: true is unnecessary here.

2. Windows Command Issue (High Priority)

Location: src/cli/commands/project/dashboard.ts:30

} else if (platform === "win32") {
  openCommand = "start";

Issue: The start command on Windows is a shell built-in, not an executable. When using execa without shell: true (as recommended above), this won't work.

Recommendation: Use a proper Windows approach:

} else if (platform === "win32") {
  openCommand = "cmd";
  await execa(openCommand, ["/c", "start", '""', dashboardUrl]);

Or better yet, use the open npm package which handles all these edge cases.

3. Missing Dependency (Medium Priority)

Issue: The codebase doesn't use the industry-standard open package for opening URLs in browsers, which handles all platform quirks, including:

• WSL support
• Various Linux desktop environments
• Edge cases with special characters in URLs
• Proper escaping

Recommendation: Add open package:

npm install open

Then simplify the implementation:

import open from 'open';

// Replace lines 23-43 with:
try {
  await open(dashboardUrl);
} catch (error) {
  log.warn("Could not open browser automatically");
  log.message(`${theme.styles.header("Dashboard")}: ${theme.colors.links(dashboardUrl)}`);
  return {};
}

This is much more robust and maintainable.

📝 Code Quality Observations

1. Authentication Not Required

Location: src/cli/commands/project/dashboard.ts:51

await runCommand(openDashboard);

Observation: Unlike the create command which uses { requireAuth: true }, this command doesn't require authentication. However, it needs a valid project ID. Consider if authentication should be required since accessing a dashboard typically requires being logged in.

Recommendation: Consider adding:

await runCommand(openDashboard, { requireAuth: true });

2. Error Message Formatting

Location: src/cli/commands/project/dashboard.ts:15-17

The error message is clear but could be more concise:

throw new Error(
  "App not configured. BASE44_CLIENT_ID environment variable is required. Set it in your .env.local file."
);

Suggestion: Consider matching the tone of other error messages in the codebase:

throw new Error(
  "App not configured. Set BASE44_CLIENT_ID in your .env.local file."
);

🧪 Test Coverage

Issue: No tests were added for this new command.

Recommendation: Add tests in tests/cli/commands/project/dashboard.test.ts covering:

• Successful browser opening
• Fallback when browser fails to open
• Error when BASE44_CLIENT_ID is missing
• URL construction with different API URLs

Example test structure:

describe('dashboard command', () => {
  it('should throw error when BASE44_CLIENT_ID is not set', async () => {
    // Test implementation
  });
  
  it('should construct correct dashboard URL', async () => {
    // Test implementation
  });
  
  it('should handle browser open failure gracefully', async () => {
    // Test implementation
  });
});

🎯 Performance Considerations

No performance concerns identified. The command is lightweight and performs minimal operations.

📋 Summary of Recommended Changes

Must Fix (High Priority):

1. Remove { shell: true } to fix security concern
2. Fix Windows start command implementation
3. Consider using the open npm package for robustness

Should Fix (Medium Priority):
4. Add test coverage
5. Consider requiring authentication

Nice to Have (Low Priority):
6. Simplify error message text

Overall Assessment

This is a useful feature that follows the project's conventions well. The main concerns are the shell injection risk and Windows compatibility. Once those are addressed, this will be ready to merge!

Let me know if you'd like help implementing any of these suggestions.

[claude]

Pull Request Review - Add Dashboard Command

Summary

This PR adds a new dashboard command that opens the app's dashboard page in the user's browser. The implementation is clean and follows the project's patterns well.

✅ Positives

• Consistent patterns: Follows the established command structure used in other commands (e.g., login, create)
• Proper error handling: Validates that BASE44_CLIENT_ID is configured before proceeding
• Good user experience: Provides clear feedback with the dashboard URL in the outro message
• Cross-platform support: Uses the open package which handles platform-specific browser opening
• Clean code: Well-structured, readable, and concise implementation

🔍 Issues & Concerns

1. Unused Imports (Code Quality)

Severity: Minor

The dashboard command imports log from @clack/prompts, execa, and theme but never uses them:

import { log } from "@clack/prompts";  // ❌ Not used
import { execa } from "execa";         // ❌ Not used
import { runCommand, theme } from "../../utils/index.js";  // theme not used

Recommendation: Remove unused imports for cleaner code:

import { Command } from "commander";
import open from 'open';
import { getBase44ApiUrl, getBase44ClientId, loadProjectEnv } from "@core/config.js";
import { runCommand } from "../../utils/index.js";
import type { RunCommandResult } from "../../utils/runCommand.js";

2. Missing User Feedback (UX)

Severity: Minor

The command doesn't provide feedback to the user that it's opening the browser. Compared to similar operations in the codebase, users typically see a loading message. The issue description (#80) specifically requested: "write a nice log saying 'Opening dashboard...'"

Current behavior:

await open(dashboardUrl);
return { outroMessage: `Dashboard opened at ${dashboardUrl}` };

Recommendation: Use runTask for consistent user feedback like other commands:

await runTask(
  "Opening dashboard...",
  async () => {
    await open(dashboardUrl);
  },
  {
    successMessage: "Dashboard opened",
    errorMessage: "Failed to open dashboard",
  }
);

3. Incorrect Dependency Declaration (Package Management)

Severity: Medium

The open package is added to devDependencies in package.json, but it should be in dependencies since it's required at runtime:

"devDependencies": {
  // ...
  "open": "^11.0.0"  // ❌ Should be in dependencies
}

Impact: When the CLI is installed via npm, devDependencies are not installed in production mode, which would cause the command to fail.

Recommendation: Move open to dependencies:

"dependencies": {
  "open": "^11.0.0"
},
"devDependencies": {
  // ... existing dev dependencies
}

4. Missing Authentication Check (Potential Issue)

Severity: Low-Medium

Other project-related commands like create use requireAuth: true in runCommand. While the dashboard command may work without authentication, it's inconsistent with the pattern and the dashboard URL might not be accessible without a valid session.

Current:

await runCommand(openDashboard);

Consider:

await runCommand(openDashboard, { requireAuth: true });

5. No Test Coverage

Severity: Medium

The PR doesn't include any tests for the new command. While testing CLI commands can be tricky, the core logic should be testable.

Recommendations:

• Add unit tests for the openDashboard function
• Test error handling when BASE44_CLIENT_ID is missing
• Mock the open function to verify correct URL construction
• Consider integration tests if the project has patterns for them

Example test structure:

describe('dashboard command', () => {
  it('should throw error when BASE44_CLIENT_ID is not configured', async () => {
    // Test implementation
  });

  it('should construct correct dashboard URL', async () => {
    // Test implementation
  });

  it('should call open with correct URL', async () => {
    // Test implementation
  });
});

🔒 Security

No security concerns identified. The command:

• Uses environment variables correctly
• Doesn't expose sensitive information
• Uses a trusted package (open) for browser launching
• Constructs URLs safely without injection risks

⚡ Performance

No performance concerns. The command is lightweight and the open package is well-optimized.

📝 Code Style

The code generally follows the project's conventions:

• ✅ Uses async/await appropriately
• ✅ Proper TypeScript typing
• ✅ Follows the command structure pattern
• ✅ Uses the runCommand wrapper
• ⚠️ Has unused imports (see Issue Add Claude Code GitHub Workflow #1)

🎯 Recommendations Priority

1. HIGH: Move open from devDependencies to dependencies
2. MEDIUM: Add test coverage for the new command
3. MEDIUM: Add user feedback with runTask (as requested in the issue)
4. LOW: Remove unused imports
5. LOW: Consider adding requireAuth: true for consistency

🎉 Conclusion

This is a solid implementation that adds useful functionality. The main blocking issue is the incorrect dependency declaration which would cause runtime failures in production. Once that's fixed along with the unused imports and user feedback, this will be ready to merge.

The code is clean, follows project patterns, and the feature request is well-addressed. Nice work! 🚀

---

Review generated with Claude Code

[claude]

Code Review for PR #82: Add dashboard command

Thank you for this contribution! The implementation is clean and follows most of the project conventions. Here are my findings:

✅ Strengths

1. Good code structure - Follows the established pattern from other commands (whoami, deploy, etc.)
2. Proper authentication - Correctly uses requireAuth: true in runCommand
3. Error handling - Validates BASE44_CLIENT_ID and provides helpful error message
4. Consistent style - Matches the codebase conventions for command structure
5. Cross-platform support - Uses the open package which handles browser opening across different OSes

🔧 Issues & Recommendations

1. Critical: Dependency in wrong section (src/cli/commands/project/dashboard.ts:2)

The open package is added to devDependencies but should be in dependencies since it's required at runtime.

Fix needed in package.json:

"dependencies": {
  "open": "^11.0.0",
  // ... other deps
},
"devDependencies": {
  // Remove from here
}

2. Style: Inconsistent quotes (src/cli/commands/project/dashboard.ts:2)

Uses single quotes for the open import while the rest of the codebase uses double quotes.

Change:

import open from 'open';  // ❌
import open from "open";  // ✅

3. Consideration: URL path consistency (src/cli/commands/project/dashboard.ts:19)

The dashboard URL uses /apps/${projectId}/editor/workspace/overview while the create command uses /apps/${projectId}/editor/preview (create.ts:219).

Question: Are these intentionally different endpoints? If so, this is fine. If they should be the same, consider using a consistent path or creating a shared helper function.

4. Enhancement: Error handling for open failure

The open() call could fail silently if no browser is available or in headless environments. Consider wrapping it with try-catch:

try {
  await open(dashboardUrl);
  return { outroMessage: `Dashboard opened at ${dashboardUrl}` };
} catch (error) {
  // If opening fails, still show the URL so users can copy it
  return { outroMessage: `Unable to open browser automatically. Visit: ${dashboardUrl}` };
}

5. Missing: Test coverage

No tests found for the new dashboard command. Consider adding tests similar to the pattern in tests/core/project.test.ts:

• Test successful dashboard opening with valid BASE44_CLIENT_ID
• Test error handling when BASE44_CLIENT_ID is missing
• Test that the correct URL is constructed

🔒 Security

✅ No security concerns identified:

• No user input is directly used in the URL (projectId comes from config)
• No command injection risks
• Authentication properly enforced

⚡ Performance

✅ No performance concerns - the command is lightweight and fast.

📝 Suggested Test Structure

// tests/cli/commands/project/dashboard.test.ts
import { describe, it, expect, vi, beforeEach } from "vitest";
import { dashboardCommand } from "../../../src/cli/commands/project/dashboard.js";

describe("dashboard command", () => {
  it("should construct correct dashboard URL", async () => {
    // Test URL construction
  });
  
  it("should throw error when BASE44_CLIENT_ID is missing", async () => {
    // Test error case
  });
});

🎯 Summary

Required changes:

1. Move open from devDependencies to dependencies
2. Change single quotes to double quotes for consistency

Recommended enhancements:
3. Add try-catch around open() for better UX
4. Add test coverage

For clarification:
5. Confirm if the different URL paths between dashboard and create commands are intentional

Overall, this is a solid implementation that just needs a couple of quick fixes before merging. Great work! 🚀

[claude]

Pull Request Review

Summary

This PR adds a new dashboard command that opens the Base44 app dashboard in the user's browser. The implementation follows the existing command patterns and integrates well with the codebase.

✅ Strengths

1. Consistent with existing patterns: The command structure follows the same pattern as other commands (e.g., login, site deploy)
2. Proper authentication: Correctly uses requireAuth: true to ensure users are authenticated
3. Cross-platform support: Uses the open package which handles browser opening across different platforms
4. Good error handling: Validates that BASE44_CLIENT_ID is configured before attempting to open the dashboard
5. User-friendly: Provides a helpful error message that tells users exactly what's needed and where to set it

🔍 Code Quality Observations

Minor Issues

1. Dependency placement (line 65 in package.json)

   • The open package is currently in devDependencies, but since it's used at runtime when users run the CLI, it should be in dependencies instead
   • This could cause issues when the package is installed in production

2. Error handling could be more robust (lines 21-23 in dashboard.ts)

   • The open() function can fail silently in some environments (SSH sessions, headless servers, containers)
   • Consider wrapping in a try-catch and providing a fallback message with the URL if opening fails
   • Example from your PR description mentions "Falls back to displaying URL if browser opening fails" but this isn't implemented in the code

3. Comment on line 8

   • The comment says "Load project environment to get the project ID" but the code is actually getting BASE44_CLIENT_ID (which is called projectId in the variable name)
   • This might be confusing - consider either updating the comment or aligning the terminology

Suggested Improvements

For the dependency issue:

// Move from devDependencies to dependencies
"dependencies": {
  "open": "^11.0.0"
}

For better error handling:

try {
  await open(dashboardUrl);
  return { outroMessage: `Dashboard opened at ${dashboardUrl}` };
} catch (error) {
  // Fallback if browser opening fails (e.g., SSH session, headless environment)
  return { outroMessage: `Could not open browser automatically. Visit: ${dashboardUrl}` };
}

For clarity:

const clientId = getBase44ClientId(); // or rename variable to match what it represents

🧪 Test Coverage

• No tests were added for the new command
• Consider adding a test to verify:
  • Error is thrown when BASE44_CLIENT_ID is not set
  • Correct URL is constructed
  • The command is properly registered

🔒 Security

• No security concerns identified
• The command properly validates authentication
• The URL construction is safe (no injection risks)

⚡ Performance

• No performance concerns
• The command is lightweight and only makes necessary calls

📝 Documentation

• The command description is clear: "Open the app dashboard in your browser"
• Consider updating the README or documentation to list this new command if applicable

Recommendation

Approve with minor changes suggested. The implementation is solid and follows best practices. The main issue is the dependency placement which should be fixed before merging. The error handling improvement is optional but would enhance user experience in edge cases.

Great work overall! 🎉