feat: cli plugin support

[ymc9]

No description provided.

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing Touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/cli-plugins

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Status, Documentation and Community

• Visit our Status Page to check the current availability of CodeRabbit.
• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[claude]

Claude finished @ymc9's task —— View job

---

PR Review: CLI Plugin Support

I've completed a thorough review of this CLI plugin support implementation. Here's my comprehensive feedback:

Todo List:

• Analyze core plugin architecture changes
• Review CLI generate action modifications
• Examine new plugin implementations (Prisma, TypeScript)
• Check test coverage for new functionality
• Assess security implications
• Evaluate performance considerations
• Provide comprehensive feedback

---

🎯 Overall Assessment: Good Implementation with Some Concerns

This PR introduces a clean plugin architecture for the CLI, but there are several important issues to address.

🔧 Code Quality & Architecture

✅ Strengths:

• Clean plugin interface with well-defined CliPlugin contract in packages/sdk/src/cli-plugin.ts:32-47
• Good separation of concerns between core and external plugins
• Proper TypeScript typing throughout the implementation
• Consistent error handling with CliError

⚠️ Issues:

1. Type Safety Concern in packages/cli/src/actions/generate.ts:67: Using (corePlugins as any)[provider.slice('@core/'.length)] breaks type safety. Consider using a typed plugin registry instead.

2. Variable Name Inconsistency in packages/cli/src/plugins/typescript.ts:10: Variable is named ourDir but should be outDir for consistency with the Prisma plugin.

🚨 Security Concerns

Critical Issue - Dynamic Import Vulnerability (packages/cli/src/actions/generate.ts:73):

cliPlugin = (await import(provider)).default as CliPlugin;

This allows arbitrary code execution by importing any module specified in the provider field. This is a high-severity security vulnerability.

Recommendations:

1. Implement a plugin allowlist/registry
2. Validate provider paths against known safe patterns
3. Consider sandboxing plugin execution
4. Add input validation for the provider field

🔍 Potential Bugs

1. Missing Error Handling: In packages/cli/src/actions/generate.ts:105-108, plugin errors are caught and logged but generation continues. Consider whether this should halt the entire process.

2. Path Traversal Risk: Both plugins use path.resolve(defaultOutputPath, pluginOptions['output']) without validating the output path, potentially allowing directory traversal attacks.

3. Plugin Ordering: The logic in generate.ts:82-87 adds default plugins in reverse order, which may be confusing and error-prone.

⚡ Performance Considerations

✅ Good:

• Plugins run sequentially with clear progress indicators
• Efficient error handling with spinners

⚠️ Concerns:

1. Sequential Execution: Plugins run one after another (generate.ts:89-109). Consider parallel execution for independent plugins.

2. Repeated File System Operations: Both plugins create directories without checking if they already exist in the same generation run.

🧪 Test Coverage

✅ Adequate:

• Good integration tests in packages/cli/test/plugins/prisma-plugin.test.ts
• Tests cover both default and custom output scenarios
• Tests verify actual file generation

📝 Missing:

• No unit tests for the plugin loading mechanism
• No tests for error scenarios (invalid plugins, failed imports)
• No tests for security edge cases

📋 Specific Recommendations

1. Security Fix (High Priority):

   // Replace dynamic import with registry-based approach
   const ALLOWED_PLUGINS = new Set(['some-trusted-plugin', 'another-plugin']);
   if (!ALLOWED_PLUGINS.has(provider)) {
     throw new CliError(`Plugin ${provider} is not in the allowed list`);
   }

2. Fix Type Safety:

   const corePluginRegistry: Record<string, CliPlugin> = {
     prisma: corePlugins.prisma,
     typescript: corePlugins.typescript,
   };

3. Add Path Validation:

   function validateOutputPath(outputPath: string): void {
     if (outputPath.includes('..') || path.isAbsolute(outputPath)) {
       throw new CliError('Invalid output path');
     }
   }

4. Improve Error Handling: Consider whether plugin failures should be fatal or just warnings.

🔄 Suggestions for Future Enhancements

• Plugin versioning and compatibility checks
• Plugin configuration validation
• Parallel plugin execution for better performance
• Plugin hooks/lifecycle events
• Better plugin discovery mechanism

📊 Summary

This is a solid foundation for a plugin system, but the security vulnerability around dynamic imports must be addressed before merging. The architecture is clean and the implementation is mostly well-structured, but security hardening is essential.

Recommendation: Request changes - address the security issue and consider the type safety improvements before approval.

---

[Copilot]

Pull Request Overview

This PR implements CLI plugin support by introducing a new plugin system architecture. The changes enable CLI plugins to be loaded and executed during code generation, replacing the previous hardcoded generation approach.

Key changes:

• Introduces a new CliPlugin interface and plugin system
• Refactors TsSchemaGenerator to accept AST models directly instead of file paths
• Adds core plugins for TypeScript and Prisma schema generation
• Updates CLI commands from zenstack to zen for brevity

Reviewed Changes

Copilot reviewed 24 out of 24 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
packages/sdk/src/cli-plugin.ts	Defines new CLI plugin interface and context types
packages/sdk/src/ts-schema-generator.ts	Refactored to accept Model AST instead of file paths
packages/cli/src/actions/generate.ts	Implements plugin loading and execution logic
packages/cli/src/plugins/	Adds core TypeScript and Prisma plugins
samples/blog/package.json	Updates CLI commands to use shorter zen syntax
Multiple tsconfig.json files	Removes redundant baseUrl configuration

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.}

[claude]

Claude finished @ymc9's task —— View job

---

PR Review: CLI Plugin Support

I've completed a thorough review of this CLI plugin support implementation. Here's my comprehensive feedback:

Todo List:

• Analyze core plugin architecture changes
• Review CLI generate action modifications
• Examine new plugin implementations (Prisma, TypeScript)
• Check test coverage for new functionality
• Assess security implications
• Evaluate performance considerations
• Provide comprehensive feedback

---

🎯 Overall Assessment: Good Implementation with Some Concerns

This PR introduces a clean plugin architecture for the CLI, but there are several important issues to address.

🔧 Code Quality & Architecture

✅ Strengths:

• Clean plugin interface with well-defined CliPlugin contract in packages/sdk/src/cli-plugin.ts:32-47
• Good separation of concerns between core and external plugins
• Proper TypeScript typing throughout the implementation
• Consistent error handling with CliError

⚠️ Issues:

1. Type Safety Concern in packages/cli/src/actions/generate.ts:67: Using (corePlugins as any)[provider.slice('@core/'.length)] breaks type safety. Consider using a typed plugin registry instead.

2. Variable Name Inconsistency in packages/cli/src/plugins/typescript.ts:10: Variable is named ourDir but should be outDir for consistency with the Prisma plugin.

🚨 Security Concerns

Critical Issue - Dynamic Import Vulnerability (packages/cli/src/actions/generate.ts:73):

cliPlugin = (await import(provider)).default as CliPlugin;

This allows arbitrary code execution by importing any module specified in the provider field. This is a high-severity security vulnerability.

Recommendations:

1. Implement a plugin allowlist/registry
2. Validate provider paths against known safe patterns
3. Consider sandboxing plugin execution
4. Add input validation for the provider field

🔍 Potential Bugs

1. Missing Error Handling: In packages/cli/src/actions/generate.ts:105-108, plugin errors are caught and logged but generation continues. Consider whether this should halt the entire process.

2. Path Traversal Risk: Both plugins use path.resolve(defaultOutputPath, pluginOptions['output']) without validating the output path, potentially allowing directory traversal attacks.

3. Plugin Ordering: The logic in generate.ts:82-87 adds default plugins in reverse order, which may be confusing and error-prone.

⚡ Performance Considerations

✅ Good:

• Plugins run sequentially with clear progress indicators
• Efficient error handling with spinners

⚠️ Concerns:

1. Sequential Execution: Plugins run one after another (generate.ts:89-109). Consider parallel execution for independent plugins.

2. Repeated File System Operations: Both plugins create directories without checking if they already exist in the same generation run.

🧪 Test Coverage

✅ Adequate:

• Good integration tests in packages/cli/test/plugins/prisma-plugin.test.ts
• Tests cover both default and custom output scenarios
• Tests verify actual file generation

📝 Missing:

• No unit tests for the plugin loading mechanism
• No tests for error scenarios (invalid plugins, failed imports)
• No tests for security edge cases

📋 Specific Recommendations

1. Security Fix (High Priority):

   // Replace dynamic import with registry-based approach
   const ALLOWED_PLUGINS = new Set(['some-trusted-plugin', 'another-plugin']);
   if (!ALLOWED_PLUGINS.has(provider)) {
     throw new CliError(`Plugin ${provider} is not in the allowed list`);
   }

2. Fix Type Safety:

   const corePluginRegistry: Record<string, CliPlugin> = {
     prisma: corePlugins.prisma,
     typescript: corePlugins.typescript,
   };

3. Add Path Validation:

   function validateOutputPath(outputPath: string): void {
     if (outputPath.includes('..') || path.isAbsolute(outputPath)) {
       throw new CliError('Invalid output path');
     }
   }

4. Improve Error Handling: Consider whether plugin failures should be fatal or just warnings.

🔄 Suggestions for Future Enhancements

• Plugin versioning and compatibility checks
• Plugin configuration validation
• Parallel plugin execution for better performance
• Plugin hooks/lifecycle events
• Better plugin discovery mechanism

📊 Summary

This is a solid foundation for a plugin system, but the security vulnerability around dynamic imports must be addressed before merging. The architecture is clean and the implementation is mostly well-structured, but security hardening is essential.

Recommendation: Request changes - address the security issue and consider the type safety improvements before approval.

---

[claude]

Claude finished @ymc9's task —— View job

---

PR Review: CLI Plugin Support

I've completed a thorough review of this CLI plugin support implementation. Here's my comprehensive feedback:

Todo List:

• Analyze core plugin architecture changes
• Review CLI generate action modifications
• Examine new plugin implementations (Prisma, TypeScript)
• Check test coverage for new functionality
• Assess security implications
• Evaluate performance considerations
• Provide comprehensive feedback

---

🎯 Overall Assessment: Good Implementation with Some Concerns

This PR introduces a clean plugin architecture for the CLI, but there are several important issues to address.

🔧 Code Quality & Architecture

✅ Strengths:

• Clean plugin interface with well-defined CliPlugin contract in packages/sdk/src/cli-plugin.ts:32-47
• Good separation of concerns between core and external plugins
• Proper TypeScript typing throughout the implementation
• Consistent error handling with CliError

⚠️ Issues:

1. Type Safety Concern in packages/cli/src/actions/generate.ts:67: Using (corePlugins as any)[provider.slice('@core/'.length)] breaks type safety. Consider using a typed plugin registry instead.

2. Variable Name Inconsistency in packages/cli/src/plugins/typescript.ts:10: Variable is named ourDir but should be outDir for consistency with the Prisma plugin.

🚨 Security Concerns

Critical Issue - Dynamic Import Vulnerability (packages/cli/src/actions/generate.ts:73):

cliPlugin = (await import(provider)).default as CliPlugin;

This allows arbitrary code execution by importing any module specified in the provider field. This is a high-severity security vulnerability.

Recommendations:

1. Implement a plugin allowlist/registry
2. Validate provider paths against known safe patterns
3. Consider sandboxing plugin execution
4. Add input validation for the provider field

🔍 Potential Bugs

1. Missing Error Handling: In packages/cli/src/actions/generate.ts:105-108, plugin errors are caught and logged but generation continues. Consider whether this should halt the entire process.

2. Path Traversal Risk: Both plugins use path.resolve(defaultOutputPath, pluginOptions['output']) without validating the output path, potentially allowing directory traversal attacks.

3. Plugin Ordering: The logic in generate.ts:82-87 adds default plugins in reverse order, which may be confusing and error-prone.

⚡ Performance Considerations

✅ Good:

• Plugins run sequentially with clear progress indicators
• Efficient error handling with spinners

⚠️ Concerns:

1. Sequential Execution: Plugins run one after another (generate.ts:89-109). Consider parallel execution for independent plugins.

2. Repeated File System Operations: Both plugins create directories without checking if they already exist in the same generation run.

🧪 Test Coverage

✅ Adequate:

• Good integration tests in packages/cli/test/plugins/prisma-plugin.test.ts
• Tests cover both default and custom output scenarios
• Tests verify actual file generation

📝 Missing:

• No unit tests for the plugin loading mechanism
• No tests for error scenarios (invalid plugins, failed imports)
• No tests for security edge cases

📋 Specific Recommendations

1. Security Fix (High Priority):

   // Replace dynamic import with registry-based approach
   const ALLOWED_PLUGINS = new Set(['some-trusted-plugin', 'another-plugin']);
   if (!ALLOWED_PLUGINS.has(provider)) {
     throw new CliError(`Plugin ${provider} is not in the allowed list`);
   }

2. Fix Type Safety:

   const corePluginRegistry: Record<string, CliPlugin> = {
     prisma: corePlugins.prisma,
     typescript: corePlugins.typescript,
   };

3. Add Path Validation:

   function validateOutputPath(outputPath: string): void {
     if (outputPath.includes('..') || path.isAbsolute(outputPath)) {
       throw new CliError('Invalid output path');
     }
   }

4. Improve Error Handling: Consider whether plugin failures should be fatal or just warnings.

🔄 Suggestions for Future Enhancements

• Plugin versioning and compatibility checks
• Plugin configuration validation
• Parallel plugin execution for better performance
• Plugin hooks/lifecycle events
• Better plugin discovery mechanism

📊 Summary

This is a solid foundation for a plugin system, but the security vulnerability around dynamic imports must be addressed before merging. The architecture is clean and the implementation is mostly well-structured, but security hardening is essential.

Recommendation: Request changes - address the security issue and consider the type safety improvements before approval.

---

[claude]

Claude finished @ymc9's task —— View job

---

Claude finished @ymc9's task —— View job

---

PR Review: CLI Plugin Support

I've completed a thorough review of this CLI plugin support implementation. Here's my comprehensive feedback:

Todo List:

• Analyze core plugin architecture changes
• Review CLI generate action modifications
• Examine new plugin implementations (Prisma, TypeScript)
• Check test coverage for new functionality
• Assess security implications
• Evaluate performance considerations
• Provide comprehensive feedback

---

🎯 Overall Assessment: Good Implementation with Some Concerns

This PR introduces a clean plugin architecture for the CLI, but there are several important issues to address.

🔧 Code Quality & Architecture

✅ Strengths:

• Clean plugin interface with well-defined CliPlugin contract in packages/sdk/src/cli-plugin.ts:32-47
• Good separation of concerns between core and external plugins
• Proper TypeScript typing throughout the implementation
• Consistent error handling with CliError

⚠️ Issues:

1. Type Safety Concern in packages/cli/src/actions/generate.ts:67: Using (corePlugins as any)[provider.slice('@core/'.length)] breaks type safety. Consider using a typed plugin registry instead.

2. Variable Name Inconsistency in packages/cli/src/plugins/typescript.ts:10: Variable is named ourDir but should be outDir for consistency with the Prisma plugin.

🚨 Security Concerns

Critical Issue - Dynamic Import Vulnerability (packages/cli/src/actions/generate.ts:73):

cliPlugin = (await import(provider)).default as CliPlugin;

This allows arbitrary code execution by importing any module specified in the provider field. This is a high-severity security vulnerability.

Recommendations:

1. Implement a plugin allowlist/registry
2. Validate provider paths against known safe patterns
3. Consider sandboxing plugin execution
4. Add input validation for the provider field

🔍 Potential Bugs

1. Missing Error Handling: In packages/cli/src/actions/generate.ts:105-108, plugin errors are caught and logged but generation continues. Consider whether this should halt the entire process.

2. Path Traversal Risk: Both plugins use path.resolve(defaultOutputPath, pluginOptions['output']) without validating the output path, potentially allowing directory traversal attacks.

3. Plugin Ordering: The logic in generate.ts:82-87 adds default plugins in reverse order, which may be confusing and error-prone.

⚡ Performance Considerations

✅ Good:

• Plugins run sequentially with clear progress indicators
• Efficient error handling with spinners

⚠️ Concerns:

1. Sequential Execution: Plugins run one after another (generate.ts:89-109). Consider parallel execution for independent plugins.

2. Repeated File System Operations: Both plugins create directories without checking if they already exist in the same generation run.

🧪 Test Coverage

✅ Adequate:

• Good integration tests in packages/cli/test/plugins/prisma-plugin.test.ts
• Tests cover both default and custom output scenarios
• Tests verify actual file generation

📝 Missing:

• No unit tests for the plugin loading mechanism
• No tests for error scenarios (invalid plugins, failed imports)
• No tests for security edge cases

📋 Specific Recommendations

1. Security Fix (High Priority):

   // Replace dynamic import with registry-based approach
   const ALLOWED_PLUGINS = new Set(['some-trusted-plugin', 'another-plugin']);
   if (!ALLOWED_PLUGINS.has(provider)) {
     throw new CliError(`Plugin ${provider} is not in the allowed list`);
   }

2. Fix Type Safety:

   const corePluginRegistry: Record<string, CliPlugin> = {
     prisma: corePlugins.prisma,
     typescript: corePlugins.typescript,
   };

3. Add Path Validation:

   function validateOutputPath(outputPath: string): void {
     if (outputPath.includes('..') || path.isAbsolute(outputPath)) {
       throw new CliError('Invalid output path');
     }
   }

4. Improve Error Handling: Consider whether plugin failures should be fatal or just warnings.

🔄 Suggestions for Future Enhancements

• Plugin versioning and compatibility checks
• Plugin configuration validation
• Parallel plugin execution for better performance
• Plugin hooks/lifecycle events
• Better plugin discovery mechanism

📊 Summary

This is a solid foundation for a plugin system, but the security vulnerability around dynamic imports must be addressed before merging. The architecture is clean and the implementation is mostly well-structured, but security hardening is essential.

Recommendation: Request changes - address the security issue and consider the type safety improvements before approval.

---