-
Notifications
You must be signed in to change notification settings - Fork 0
Release v1.0 #6
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
Release v1.0 #6
Conversation
use docker check fix
F/api domain config
Major update to CLI documentation in README.md, including detailed usage, command explanations, and vnext.config.json support. Adds new src/lib/vnextConfig.js for reading project config, improves logging and user feedback in check, csx, reset, and sync commands, and updates package metadata. Enhances component discovery, error handling, and summary reporting for all major commands.
…ons-with-external-version-management Revamp CLI docs, improve commands, add vnextConfig
Reviewer's GuideRefactors the CLI to be driven by a new vnext.config.json project descriptor, updates CSX/JSON discovery and processing to respect that config, unifies publishing logic around a new definitions API, improves logging and summaries for csx/sync/update/reset/check commands, and clarifies README/config usage to match the new behavior. Sequence diagram for wf sync command with new vnext.config.json driven flowsequenceDiagram
actor Dev
participant CLI as wf_sync_command
participant Config as ConfigLib
participant VConf as VnextConfig
participant Disc as DiscoverLib
participant Csx as CsxLib
participant WF as WorkflowLib
participant DB as DbLib
participant API as ApiLib
Dev->>CLI: run wf sync
CLI->>Config: get(PROJECT_ROOT, DB_*, API_*, AUTO_DISCOVER)
Config-->>CLI: projectRoot, dbConfig, apiConfig
CLI->>VConf: getDomain(projectRoot)
VConf-->>CLI: domain
CLI->>Disc: discoverComponents(projectRoot)
Disc->>VConf: getComponentsRoot(projectRoot)
Disc->>VConf: getComponentTypes(projectRoot)
Disc-->>CLI: discovered componentDirs
CLI->>Csx: findAllCsx(projectRoot)
Csx->>Disc: findAllCsxInComponents(projectRoot)
Disc-->>Csx: csxPaths
Csx-->>CLI: csxPaths
loop for each csxPath
CLI->>Csx: processCsxFile(csxPath, projectRoot)
Csx->>Csx: readNativeContent, encodeToBase64
Csx->>Csx: findJsonFilesForCsx(csxPath, projectRoot)
Csx->>Disc: discoverComponents(projectRoot)
Csx->>Disc: findAllJsonFiles(discovered)
loop for each related JSON
Csx->>Csx: updateCodeInJson(jsonPath, csxLocation, base64Code, nativeCode)
end
Csx-->>CLI: result (updatedJsonCount, totalUpdates)
end
CLI->>Disc: findAllJsonFiles(discovered)
Disc-->>CLI: jsonInfos
loop for each jsonInfo
CLI->>WF: getJsonMetadata(jsonPath)
WF-->>CLI: metadata(key, version, data, flow)
CLI->>WF: detectComponentType(jsonPath, projectRoot)
WF-->>CLI: componentType
CLI->>DB: getInstanceId(dbConfig, flow, key, version)
DB-->>CLI: existingId or null
alt not exists
CLI->>API: publishComponent(apiBaseUrl, metadata.data)
API-->>CLI: { success, data or error }
else exists and sync
CLI->>DB: deleteWorkflow(dbConfig, flow, existingId)
DB-->>CLI: deleted
CLI->>API: publishComponent(apiBaseUrl, metadata.data)
API-->>CLI: { success, data or error }
end
end
CLI->>API: reinitializeSystem(apiBaseUrl, apiVersion)
API-->>CLI: success
CLI-->>Dev: summary per component type and CSX
Class diagram for updated CLI core modules and commandsclassDiagram
class ConfigLib {
+get(key)
+set(key, value)
+getAll()
+clear()
+path
}
class VnextConfig {
+loadVnextConfig(projectRoot)
+getDomain(projectRoot)
+getPaths(projectRoot)
+getComponentsRoot(projectRoot)
+getComponentTypes(projectRoot)
+getFullConfig(projectRoot)
+clearCache()
}
class DiscoverLib {
+discoverComponents(projectRoot)
+findJsonInComponent(componentDir)
+findAllJsonFiles(discovered)
+findAllCsxInComponents(projectRoot)
+getComponentDir(discovered, component)
+listDiscovered(discovered, componentTypes)
+detectComponentTypeFromPath(filePath, componentTypes)
}
class WorkflowLib {
+getJsonMetadata(jsonPath)
+detectComponentType(jsonPath, projectRoot)
+processComponent(jsonPath, dbConfig, baseUrl, projectRoot)
+getGitChangedJson(projectRoot)
+findAllJsonInComponent(componentDir)
+findAllJson(discovered)
}
class ApiLib {
+testApiConnection(baseUrl)
+publishComponent(baseUrl, componentData)
+reinitializeSystem(baseUrl, version)
}
class DbLib {
+testDbConnection(dbConfig)
+getInstanceId(dbConfig, flow, key, version)
+deleteWorkflow(dbConfig, flow, instanceId)
}
class CsxLib {
+encodeToBase64(csxPath)
+readNativeContent(csxPath)
+findJsonFilesForCsx(csxPath, projectRoot)
+getCsxLocation(csxPath, projectRoot)
+updateCodeInJson(jsonPath, csxLocation, base64Code, nativeCode)
+processCsxFile(csxPath, projectRoot)
+getGitChangedCsx(projectRoot)
+findAllCsx(projectRoot)
}
class CommandCheck {
+checkCommand()
}
class CommandSync {
+syncCommand()
}
class CommandUpdate {
+updateCommand(options)
}
class CommandReset {
+resetCommand(options)
}
class CommandCsx {
+csxCommand(options)
}
class CommandConfig {
+configCommand(action, key, value)
}
%% Relationships
CommandCheck --> ConfigLib
CommandCheck --> DiscoverLib
CommandCheck --> VnextConfig
CommandCheck --> ApiLib
CommandCheck --> DbLib
CommandSync --> ConfigLib
CommandSync --> DiscoverLib
CommandSync --> VnextConfig
CommandSync --> CsxLib
CommandSync --> WorkflowLib
CommandSync --> DbLib
CommandSync --> ApiLib
CommandUpdate --> ConfigLib
CommandUpdate --> DiscoverLib
CommandUpdate --> VnextConfig
CommandUpdate --> CsxLib
CommandUpdate --> WorkflowLib
CommandUpdate --> DbLib
CommandUpdate --> ApiLib
CommandReset --> ConfigLib
CommandReset --> DiscoverLib
CommandReset --> VnextConfig
CommandReset --> WorkflowLib
CommandReset --> DbLib
CommandReset --> ApiLib
CommandCsx --> ConfigLib
CommandCsx --> VnextConfig
CommandCsx --> CsxLib
CommandConfig --> ConfigLib
DiscoverLib --> VnextConfig
WorkflowLib --> DbLib
WorkflowLib --> ApiLib
WorkflowLib --> DiscoverLib
WorkflowLib --> VnextConfig
CsxLib --> DiscoverLib
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Rate limit exceeded@yilmaztayfun has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 19 minutes and 39 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (15)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
Summary of ChangesHello @yilmaztayfun, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a fundamental architectural change to the workflow CLI, shifting project configuration to a centralized Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
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.
Hey there - I've reviewed your changes - here's some feedback:
- The LOG helper object is duplicated across multiple commands (update, sync, reset, csx, check); consider extracting it into a shared utility module to avoid repetition and keep logging behavior consistent in one place.
- There are a few unused imports and parameters (e.g., findAllJsonFiles in update.js, deleteWorkflow in sync.js, projectRoot in getCsxLocation, detectComponentTypeFromPath in discover.js); cleaning these up will simplify the code and reduce confusion about which utilities are actually in use.
- The logic for normalizing USE_DOCKER values from config (treating both boolean true and string 'true' as enabled) is repeated in several commands; centralizing this normalization in the config layer (or a small helper) would make behavior more predictable and easier to maintain.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The LOG helper object is duplicated across multiple commands (update, sync, reset, csx, check); consider extracting it into a shared utility module to avoid repetition and keep logging behavior consistent in one place.
- There are a few unused imports and parameters (e.g., findAllJsonFiles in update.js, deleteWorkflow in sync.js, projectRoot in getCsxLocation, detectComponentTypeFromPath in discover.js); cleaning these up will simplify the code and reduce confusion about which utilities are actually in use.
- The logic for normalizing USE_DOCKER values from config (treating both boolean true and string 'true' as enabled) is repeated in several commands; centralizing this normalization in the config layer (or a small helper) would make behavior more predictable and easier to maintain.
## Individual Comments
### Comment 1
<location> `src/lib/csx.js:101` </location>
<code_context>
- obj.code = base64Code;
- return true;
+ // Check encoding type: NAT = Native (plain text), B64 or empty = Base64 (default)
+ const encoding = obj.encoding ? obj.encoding.toUpperCase() : 'B64';
+
+ if (encoding === 'NAT') {
</code_context>
<issue_to_address>
**issue (bug_risk):** Guard against non-string `encoding` values to avoid runtime errors.
If `obj.encoding` is not a string (e.g. boolean/number), `.toUpperCase()` will throw and stop processing the JSON. Consider guarding the type, e.g.:
```js
const encoding = typeof obj.encoding === 'string'
? obj.encoding.toUpperCase()
: 'B64';
```
</issue_to_address>
### Comment 2
<location> `src/lib/discover.js:14` </location>
<code_context>
+ // Component statistics
+ console.log(chalk.white.bold('\n Component Publish Results:\n'));
+
+ const componentTypes = getComponentTypes(projectRoot);
+ for (const [type, folderName] of Object.entries(componentTypes)) {
+ const stats = componentStats[type];
</code_context>
<issue_to_address>
**issue (bug_risk):** Component type detection from path uses `/` separators and may fail on Windows.
In `detectComponentTypeFromPath`, the match uses `/` in `folderPattern`, but Windows paths typically contain `\`, so the check may never succeed and the function will default to `'unknown'`. Consider normalizing path separators (e.g., via `path.normalize` and `path.sep`) or reusing the approach from `detectComponentType` in `workflow.js` so both helpers share a consistent, cross-platform implementation.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| obj.code = base64Code; | ||
| return true; | ||
| // Check encoding type: NAT = Native (plain text), B64 or empty = Base64 (default) | ||
| const encoding = obj.encoding ? obj.encoding.toUpperCase() : 'B64'; |
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.
issue (bug_risk): Guard against non-string encoding values to avoid runtime errors.
If obj.encoding is not a string (e.g. boolean/number), .toUpperCase() will throw and stop processing the JSON. Consider guarding the type, e.g.:
const encoding = typeof obj.encoding === 'string'
? obj.encoding.toUpperCase()
: 'B64';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.
Code Review
The pull request introduces significant changes to the CLI tool, primarily focusing on integrating a new vnext.config.json file for project configuration. This includes updating the README.md to document the new configuration, detailing command usage, and clarifying that PROJECT_ROOT is now automatically derived from the current working directory. The core logic across check.js, csx.js, reset.js, sync.js, and update.js commands has been refactored to leverage this vnext.config.json for component discovery and type mapping, replacing hardcoded component lists. A new vnextConfig.js module was added to handle reading and caching this configuration. The api.js module was updated to introduce a generic publishComponent function and modify the reinitialization endpoint. The csx.js module now supports updating multiple CSX references within a single JSON file and handles both Base64 and native encoding. Logging has been standardized across commands with a new LOG helper. Additionally, the package name was updated in package.json and package-lock.json, and .gitignore was modified. Review comments highlighted a typo in the reset command's interactive menu, suggesting 'ALL' instead of 'TUMU', and pointed out a case-sensitivity issue in the useDocker configuration check across multiple command files, recommending a case-insensitive comparison for robustness.
| schemas (Schemas/) | ||
| ────────────── | ||
| 🔴 ALL (All folders) | ||
| TUMU (All folders) |
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.
| user: config.get('DB_USER'), | ||
| password: config.get('DB_PASSWORD'), | ||
| useDocker: config.get('USE_DOCKER'), | ||
| useDocker: useDockerValue === true || useDockerValue === '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.
The check for useDockerValue only considers the boolean true and the lowercase string 'true'. If a user configures this value as 'TRUE' or any other case variation, this check will evaluate to false, potentially leading to incorrect database connection behavior. It would be more robust to perform a case-insensitive comparison. This same issue is present in reset.js, sync.js, and update.js.
| useDocker: useDockerValue === true || useDockerValue === 'true', | |
| useDocker: String(useDockerValue).toLowerCase() === 'true', |
| user: config.get('DB_USER'), | ||
| password: config.get('DB_PASSWORD'), | ||
| useDocker: config.get('USE_DOCKER'), | ||
| useDocker: useDockerValue === true || useDockerValue === '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.
Similar to the issue in check.js, this check for useDockerValue is case-sensitive. It only handles boolean true and lowercase 'true'. This could lead to unexpected behavior if the config value is set to something like 'TRUE'. A case-insensitive comparison would be more robust.
| useDocker: useDockerValue === true || useDockerValue === 'true', | |
| useDocker: String(useDockerValue).toLowerCase() === 'true', |
| user: config.get('DB_USER'), | ||
| password: config.get('DB_PASSWORD'), | ||
| useDocker: config.get('USE_DOCKER'), | ||
| useDocker: useDockerValue === true || useDockerValue === '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.
Similar to the issue in check.js, this check for useDockerValue is case-sensitive. It only handles boolean true and lowercase 'true'. This could lead to unexpected behavior if the config value is set to something like 'TRUE'. A case-insensitive comparison would be more robust.
| useDocker: useDockerValue === true || useDockerValue === 'true', | |
| useDocker: String(useDockerValue).toLowerCase() === 'true', |
| user: config.get('DB_USER'), | ||
| password: config.get('DB_PASSWORD'), | ||
| useDocker: config.get('USE_DOCKER'), | ||
| useDocker: useDockerValue === true || useDockerValue === '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.
Similar to the issue in check.js, this check for useDockerValue is case-sensitive. It only handles boolean true and lowercase 'true'. This could lead to unexpected behavior if the config value is set to something like 'TRUE'. A case-insensitive comparison would be more robust.
| useDocker: useDockerValue === true || useDockerValue === 'true', | |
| useDocker: String(useDockerValue).toLowerCase() === 'true', |
Summary by Sourcery
Align CLI with vNext configuration-driven component discovery and publishing, improve CSX handling, and enhance command UX and diagnostics.
Enhancements:
Documentation: