feat(cli): log dashboard link and default login to false

[dor-chaouat]

No description provided.

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/[email protected]

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

npm i "base44@npm:@base44-preview/[email protected]"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/[email protected]"
  }
}

• 📦 Preview Package: @base44-preview/[email protected]
• 🔗 View this commit on GitHub

---

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

[claude]

Pull Request Review: feat(cli): log dashboard link and default login to false

Summary

This PR adds two features:

1. Logs the dashboard link after project creation
2. Sets the default public_settings to "public_without_login" for new projects

Code Quality ✅

The code changes are clean and well-structured:

• Properly destructures projectId from the result
• Correctly threads the projectId through the return types
• The TypeScript types are properly updated in CreateProjectResult interface

Issues Found 🔴

1. Hardcoded Preview URL (Critical)

Location: src/cli/commands/project/create.ts:75

The dashboard URL is hardcoded to https://pr-2624.velino.org, which appears to be a PR preview environment:

log.success(`Dashboard link:\n${chalk.bold(`https://pr-2624.velino.org/apps/${projectId}/editor/preview`)}`);

Problem: This will break in production and point users to the wrong environment.

Recommendation: Use the same environment-aware approach as the API client:

const apiUrl = getBase44ApiUrl(); // Returns BASE44_API_URL or default
const dashboardUrl = apiUrl.replace('app.base44.com', 'app.base44.com'); // Or separate env var
log.success(`Dashboard link:\n${chalk.bold(`${dashboardUrl}/apps/${projectId}/editor/preview`)}`);

Consider adding a getBase44DashboardUrl() function to src/core/config.ts similar to getBase44ApiUrl().

2. No Validation for public_settings Value

Location: src/core/project/api.ts:10

The value "public_without_login" is hardcoded without validation or explanation.

Questions:

• What are the valid values for public_settings?
• Should this be configurable by users?
• Is this the right default for all projects?

Recommendation:

• Document the valid values as a TypeScript union type or enum
• Consider making this configurable via a CLI flag or prompt
• Add a comment explaining the security implications of this default

Security Concerns ⚠️

Default Public Without Login

Setting public_settings: "public_without_login" by default means all new projects will be publicly accessible without authentication.

Considerations:

• Is this the desired default for all users?
• Should there be a warning or confirmation prompt?
• Consider making this an explicit choice during project creation

Recommendation: Either:

1. Add a prompt asking users to choose the security level, or
2. Clearly document this behavior in the CLI output/docs

Test Coverage 📋

Missing Tests:

• No tests for the new projectId return value
• No tests for the dashboard URL logging
• No tests for the public_settings parameter

Recommendation: Add tests in tests/core/project.test.ts:

it("returns projectId from createProjectFiles", async () => {
  const result = await createProjectFiles({...});
  expect(result.projectId).toBeDefined();
  expect(typeof result.projectId).toBe("string");
});

Performance Considerations ✅

No performance concerns - the changes are minimal and don't introduce any additional API calls or blocking operations.

Best Practices Suggestions

1. Extract URL construction into a utility function for testability
2. Add JSDoc comments for the new interface properties:

export interface CreateProjectResult {
  /** The unique identifier for the created project */
  projectId: string;
  projectDir: string;
}

3. Consider internationalization - the dashboard link message might need i18n in the future

Action Items

Must Fix Before Merge:

• Replace hardcoded pr-2624.velino.org with environment-aware URL

Recommended:

• Add tests for new functionality
• Document or make public_settings configurable
• Add user confirmation or warning about public access default
• Add JSDoc comments for new interface properties

Consider:

• Extract dashboard URL construction into a testable utility function
• Add environment variable for dashboard URL separate from API URL

---

Overall, this is a useful feature addition, but the hardcoded preview URL is a blocking issue that must be fixed before merge. The security implications of the default public access should also be carefully considered.

[claude]

Code Review for PR #22: feat(cli): log dashboard link and default login to false

Summary

This PR adds two improvements to the project creation flow:

1. Displays the dashboard link after project creation
2. Sets new projects to public without login by default

Positive Aspects ✅

• Good type safety: Properly updated the CreateProjectResult interface to include projectId
• Clean implementation: The changes flow logically from API → core logic → CLI output
• User experience: Displaying the dashboard link is helpful for immediate project access

Issues & Suggestions 🔍

1. Hardcoded Default Behavior (High Priority)

Location: src/core/project/api.ts:10

public_settings: "public_without_login"

Issue: This hardcodes all new projects to be public without login. This is a significant security default that:

• Could expose sensitive data if users don't realize their project is public
• Removes user choice in a security-critical decision
• May not be appropriate for all use cases

Suggestions:

• Consider making this configurable via a CLI flag (e.g., --public, --auth-required)
• Add a prompt during project creation asking about authentication requirements
• At minimum, add a warning message informing users their project is public
• Document this behavior clearly in the command help text

2. Missing Type Safety for public_settings

Location: src/core/project/api.ts:10

Issue: The value "public_without_login" is a magic string with no type validation. If the API expects specific values, there's no compile-time checking.

Suggestion: Consider creating a type or enum:

type PublicSettings = "public_without_login" | "public_with_login" | "private";

3. URL Construction Without Validation

Location: src/cli/commands/project/create.ts:75

`https://app.base44.com/apps/${projectId}/editor/preview`

Issue: The projectId is directly interpolated without validation or encoding. While likely safe if coming from the API, defensive programming suggests validation.

Suggestions:

• Add URL encoding: encodeURIComponent(projectId)
• Consider extracting the base URL to a constant for easier configuration

4. Inconsistent Message Formatting

Location: src/cli/commands/project/create.ts:75

log.success(`Dashboard link:\n${chalk.bold(`https://app.base44.com/apps/${projectId}/editor/preview`)}`);

Issue: The newline \n might not render consistently across all terminals. Also, using two log.success calls (lines 74-75) could be consolidated.

Suggestion:

log.success(`Project ${chalk.bold(name)} has been initialized!`);
log.info(`Dashboard: ${chalk.bold(`https://app.base44.com/apps/${projectId}/editor/preview`)}`);

This provides visual separation and uses a more semantic log level for informational content.

5. Missing Test Coverage

Issue: No tests were added for:

• The new public_settings field in API calls
• The dashboard link display logic
• The projectId being properly returned and used

Suggestion: Add tests to tests/core/project.test.ts or create new test files to verify:

• The API call includes the correct public_settings value
• The CreateProjectResult includes projectId
• The dashboard URL is correctly formatted

6. Documentation Gap

Issue: The PR description is empty, making it unclear:

• Why defaulting to public without login is the desired behavior
• What the expected user impact is
• Whether this is a breaking change for existing users

Suggestion: Add context in the PR description explaining the rationale.

Performance Considerations ⚡

No performance concerns identified. The changes are minimal and don't introduce any expensive operations.

Security Concerns 🔒

Critical: The most significant concern is the security implication of defaulting to public_without_login. This means:

• All new projects are publicly accessible by default
• No authentication is required to access project data
• Users may not realize they need to change this setting

Recommendation: This should be either:

1. Made explicit with a prompt during creation
2. Clearly documented with a warning message
3. Made configurable with a sensible default (possibly private/with-login)

Additional Notes

Consider adding:

• A help message or docs link about project visibility settings
• A --private or --auth flag for security-conscious users
• A post-creation message explaining how to change security settings

Overall Assessment

The code quality is good with proper TypeScript usage, but the security implications of the default behavior need attention. I'd recommend addressing the public-by-default behavior before merging.

Would you like me to suggest specific implementation approaches for any of these items?

[kfirstri]

🚀

[claude]

Pull Request Review

Overview

This PR adds a dashboard link to the output after project creation and defaults new projects to public_without_login access. Overall the changes are well-structured and functional, but there are a few items to address.

---

✅ Positive Aspects

1. Clear feature addition: The dashboard link provides immediate value to users by giving them quick access to their newly created project
2. Type safety maintained: The CreateProjectResult interface is properly updated to include projectId
3. Clean data flow: The projectId is correctly threaded through the call chain from API → createProjectFiles → CLI command
4. Good use of existing utilities: Leverages getBase44ApiUrl() for environment-aware URL construction

---

🐛 Issues Found

1. Unused Import (src/cli/commands/project/create.ts:10)

The printBanner import is added but never used in the file. This should be removed to keep the code clean.

// Current:
import { runCommand, runTask, printBanner, onPromptCancel } from "../../utils/index.js";

// Should be:
import { runCommand, runTask, onPromptCancel } from "../../utils/index.js";

---

⚠️ Concerns & Suggestions

1. Security: Hardcoded Public Access Setting (src/core/project/api.ts:10)

The public_settings: "public_without_login" is now hardcoded for ALL new projects. This is a significant security decision that:

• Makes all new projects publicly accessible without authentication by default
• Could expose sensitive data if users don't realize this is the default
• Removes the ability for users to choose their preferred security model during creation

Recommendations:

• Consider making this configurable via a CLI flag: --public or --access-level <level>
• At minimum, add a clear warning message during project creation informing users that the project will be publicly accessible
• Consider if this aligns with security best practices for your platform

Example warning message:

log.warn(`⚠️  Project will be publicly accessible without login. You can change this in the dashboard.`);

2. URL Construction & Edge Cases (src/cli/commands/project/create.ts:76)

The dashboard URL is constructed as:

`${getBase44ApiUrl()}/apps/${projectId}/editor/preview`

Considerations:

• The API URL may include a trailing slash in some environments (e.g., from BASE44_API_URL env var), which would create URLs like https://app.base44.com//apps/...
• The projectId should be URL-encoded if it could contain special characters (though UUIDs are typically safe)

Suggestion:

const apiUrl = getBase44ApiUrl().replace(/\/$/, ''); // Remove trailing slash
const dashboardUrl = `${apiUrl}/apps/${encodeURIComponent(projectId)}/editor/preview`;
log.success(`Dashboard link:\n${chalk.bold(dashboardUrl)}`);

3. Output Formatting (src/cli/commands/project/create.ts:76)

The newline character in the log message may not render consistently across all terminals:

log.success(`Dashboard link:\n${chalk.bold(...)}`);

Suggestion for better formatting:

log.success(`Project ${chalk.bold(name)} has been initialized!`);
log.info(`Dashboard: ${chalk.bold(chalk.cyan(`${apiUrl}/apps/${projectId}/editor/preview`))}`);

This separates concerns and uses appropriate log levels (success vs info) with color coding for the URL.

---

🧪 Test Coverage

Missing test coverage:

• No tests verify that projectId is correctly returned from createProjectFiles
• No tests for the dashboard URL construction
• No tests for the new public_settings parameter in the API call

Recommendations:
Add tests to tests/core/project.test.ts or create integration tests that verify:

1. createProjectFiles returns a valid projectId
2. The dashboard URL is correctly formatted
3. The API is called with the expected public_settings value

---

📊 Performance

No performance concerns identified. The changes add minimal overhead.

---

📋 Summary

Must fix:

• Remove unused printBanner import

Should address:

• Reconsider the hardcoded public_without_login setting or add user warning/choice
• Handle potential trailing slashes in API URL
• Add test coverage for the new functionality

Nice to have:

• Improve output formatting for better UX
• URL-encode the projectId for safety

---

Verdict

The core functionality works well, but the security implications of defaulting to public access need careful consideration. Please address the unused import and consider the security concerns before merging.

[claude]

Pull Request Review

Summary

This PR adds two features:

1. Logs the dashboard link after project creation
2. Sets public_settings to "public_without_login" by default

Code Quality & Best Practices

✅ Strengths

• Clean integration: The changes follow existing patterns in the codebase
• Type safety: Properly added projectId to the CreateProjectResult interface (src/core/project/create.ts:14-15)
• Good separation of concerns: API change is isolated in api.ts, UI change in create.ts
• Proper destructuring: Correctly destructures projectId from the result (src/cli/commands/project/create.ts:59)

⚠️ Potential Issues

1. Hardcoded Setting without Configuration Option

Location: src/core/project/api.ts:10

The public_settings: "public_without_login" is now hardcoded for all new projects. This removes the ability for users to create projects with different access settings.

Suggestion: Consider:

• Making this configurable via a CLI flag (e.g., --login-required)
• Adding it as a prompt during project creation
• Documenting this behavior change if it's intentional

// Example approach:
export async function createProject(
  projectName: string, 
  description?: string,
  requireLogin = false  // Add parameter with default
) {
  const response = await base44Client.post("api/apps", {
    json: {
      name: projectName,
      user_description: description ?? `Backend for '${projectName}'`,
      app_type: "baas",
      public_settings: requireLogin ? "public_with_login" : "public_without_login"
    },
  });
  // ...
}

2. URL Construction Could Be Fragile

Location: src/cli/commands/project/create.ts:76

The dashboard URL is constructed by string concatenation. If the API URL ends with a trailing slash or the path structure changes, this could break.

Suggestion: Consider a more robust URL construction:

const dashboardUrl = new URL(`/apps/${projectId}/editor/preview`, getBase44ApiUrl());
log.success(`Dashboard link:\n${chalk.bold(dashboardUrl.toString())}`);

3. Missing URL Validation

The projectId comes from the API response but isn't validated before being used in the URL. If the API returns an unexpected format, the dashboard link could be malformed.

Suggestion: Add basic validation or handle edge cases:

if (!projectId) {
  log.warn("Unable to generate dashboard link");
} else {
  log.success(`Dashboard link:\n${chalk.bold(`${getBase44ApiUrl()}/apps/${projectId}/editor/preview`)}`);
}

Security Considerations

⚠️ Authentication Default Change

Setting public_without_login as the default makes all new projects publicly accessible without authentication. This could be a security concern if users don't understand the implications.

Recommendations:

1. Add a clear warning or confirmation during project creation
2. Document this behavior prominently in user-facing documentation
3. Consider making this an explicit choice rather than a silent default
4. Add a message after creation explaining the security implications:

   log.info(`Your project is configured as public without login. You can change this in the dashboard.`);

Performance Considerations

No performance concerns identified. The changes are minimal and don't introduce any additional network calls or computational overhead.

Test Coverage

❌ Missing Tests

The changes lack test coverage:

1. No tests for dashboard URL generation: The URL construction in create.ts:76 isn't tested
2. No tests for the new public_settings parameter: The API call change isn't verified
3. No tests for projectId return value: The updated interface should have tests

Suggestions:

• Add unit tests for the URL construction logic
• Add integration tests verifying the API call includes the correct public_settings value
• Update existing tests in tests/core/project.test.ts if they mock the createProject function
• Consider adding an E2E test that verifies the complete flow including the dashboard link output

Additional Recommendations

1. User Experience: The dashboard link is valuable, but consider:

   • Opening the link automatically (with user consent): Do you want to open the dashboard? (y/n)
   • Copying it to clipboard automatically on supported platforms

2. Error Handling: If getBase44ApiUrl() returns an invalid URL, the output will be confusing. Consider validating it.

3. Documentation: Update any relevant documentation to reflect:

   • The new default authentication setting
   • The dashboard link feature
   • How to modify project security settings after creation

Verdict

The code is well-structured and follows existing patterns, but there are some concerns:

Approve with suggestions ✅ (if the hardcoded security default is intentional)
Request changes ⚠️ (if configurability or tests are required)

The main concerns are:

1. Lack of test coverage for new functionality
2. Hardcoded security setting without user awareness
3. Potential URL construction edge cases

The dashboard link feature is a nice quality-of-life improvement, but the authentication default change should be carefully considered from a security perspective.