v1.0.3#9
Conversation
Release v1.0
…nagement Closes #7 This change introduces a structured multidomain configuration model to eliminate manual environment switching and reduce operational risk during domain transitions. Previously, switching domains required manual updates to critical runtime parameters such as API_BASE_URL and DB_NAME. This approach was error-prone and operationally inefficient. The new implementation provides centralized, domain-scoped configuration management with automatic activation and backward compatibility. Architectural Enhancements Config Layer Refactor (src/lib/config.js) - Transitioned from a flat configuration model to a structured ACTIVE_DOMAIN + DOMAINS[] architecture - Implemented automatic migration from legacy single-domain format - Updated get/set operations to resolve against the active domain context - Introduced domain lifecycle management methods: - addDomain() - useDomain() - listDomains() - removeDomain() - Enhanced clear() to safely reset to the default domain - Preserved full backward compatibility for existing installations CLI Capabilities (src/commands/domain.js) - Added a dedicated `domain` command namespace with: - active → displays current active domain - list → enumerates configured domains - add → registers a new domain (inherits missing defaults) - use → switches active domain and applies configuration atomically - remove → removes a domain (default domain protected) Config Command Improvements (src/commands/config.js) - Enriched `config get` output with active domain visibility - Filtered internal metadata fields from user-facing output CLI Registration (bin/workflow.js) - Fully registered domain command with complete option definitions and contextual help messaging Documentation Updates (README.md) - Added comprehensive “Multidomain Support” section - Documented migration behavior and backward compatibility guarantees - Updated configuration file schema documentation - Added usage examples and workflow scenarios - Reflected structural changes in project layout Impact - Reduces configuration-related operational errors - Improves environment isolation and runtime consistency - Enables scalable multi-environment workflows - Maintains backward compatibility with zero-breaking changes
Address code review findings from #7 to improve robustness and safety: - Use conf API (config.delete/config.set/config.clear) instead of directly replacing config.store in migrateConfig() and clear(), avoiding bypass of conf internals (schema, encryption, migrations) - Replace generic parseValue() with key-aware coerceValue() that only converts known numeric keys (DB_PORT) to number and known boolean keys (AUTO_DISCOVER, USE_DOCKER, DEBUG_MODE) to boolean, preventing unintended type coercion on values like DB_PASSWORD=1234 - Protect reserved keys (PROJECT_ROOT, DOMAIN_NAME, ACTIVE_DOMAIN) in set() by throwing an error instead of silently succeeding, ensuring active-domain lookup remains consistent - Add try/catch in configCommand for set action so reserved key errors are displayed cleanly instead of crashing - Use Commander's Argument.choices() for domain action validation, providing automatic error messages for invalid actions - Expand README migration example to show all 11 default config keys instead of only 2, giving readers the full picture of the migration Closes #7
Address PR review feedback requesting English help descriptions. Translated all CLI --help descriptions, options, and examples in workflow.js to English for consistency. Also translated Turkish JSDoc and inline comments in api.js and db.js (comment-only changes). Co-authored-by: Cursor <cursoragent@cursor.com>
…switching-for-multidomain-runtime-usage feat(config): introduce enterprise-grade multidomain configuration management
Reviewer's GuideIntroduce domain-aware configuration with multi-domain CLI support, including automatic migration from the old flat config format, new domain management commands, and updated documentation and messaging in English. Sequence diagram for wf domain add and use with domain-aware configsequenceDiagram
actor User
participant WorkflowCLI
participant DomainCommand
participant ConfigLib
participant ConfStore
User->>WorkflowCLI: wf domain add staging --API_BASE_URL ...
WorkflowCLI->>DomainCommand: domainCommand(add, "staging", options)
DomainCommand->>DomainCommand: extractOptions(options)
DomainCommand->>ConfigLib: addDomain("staging", parsedOptions)
ConfigLib->>ConfStore: get(DOMAINS)
ConfStore-->>ConfigLib: domains[] or []
ConfigLib->>ConfStore: set(DOMAINS, updatedDomains)
ConfigLib-->>DomainCommand: newDomain
DomainCommand->>User: print success and domain config
User->>WorkflowCLI: wf domain use staging
WorkflowCLI->>DomainCommand: domainCommand(use, "staging", options)
DomainCommand->>ConfigLib: useDomain("staging")
ConfigLib->>ConfStore: get(DOMAINS)
ConfStore-->>ConfigLib: domains[]
ConfigLib->>ConfStore: set(ACTIVE_DOMAIN, "staging")
ConfigLib-->>DomainCommand: void
DomainCommand->>ConfigLib: getActiveDomainConfig()
ConfigLib->>ConfStore: get(ACTIVE_DOMAIN), get(DOMAINS)
ConfStore-->>ConfigLib: activeDomain, domains[]
ConfigLib-->>DomainCommand: activeDomainConfig
DomainCommand->>User: show applied API_BASE_URL and DB_NAME
Class diagram for domain-aware config and domain command modulesclassDiagram
class ConfStore {
+store
+get(key)
+set(key, value)
+delete(key)
+clear()
+path
}
class ConfigLib {
+DEFAULT_DOMAIN_CONFIG
+getActiveDomainConfig()
+get(key)
+set(key, value)
+getAll()
+clear()
+addDomain(name, options)
+useDomain(name)
+listDomains()
+removeDomain(name)
}
class DomainCommand {
+domainCommand(action, name, options)
+showActiveDomain()
+addDomain(name, options)
+useDomain(name)
+listDomains()
+removeDomain(name)
+printDomainConfig(domain)
}
class WorkflowCLI {
+checkCommand()
+csxCommand()
+updateCommand()
+syncCommand()
+resetCommand()
+configCommand(action, key, value)
+domainCommand(action, name, options)
}
class ConfigFile {
+ACTIVE_DOMAIN
+DOMAINS
+DOMAIN_NAME
+AUTO_DISCOVER
+API_BASE_URL
+API_VERSION
+DB_HOST
+DB_PORT
+DB_NAME
+DB_USER
+DB_PASSWORD
+USE_DOCKER
+DOCKER_POSTGRES_CONTAINER
+DEBUG_MODE
}
ConfigLib --> ConfStore : wraps
DomainCommand --> ConfigLib : uses
WorkflowCLI --> DomainCommand : invokes
WorkflowCLI --> ConfigLib : uses
ConfigLib --> ConfigFile : persists
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 significantly enhances the CLI by integrating robust multidomain capabilities. Users can now define and effortlessly switch between various configuration environments, streamlining workflow management across different stages of development or deployment. The changes include a new command for domain operations, a refactored configuration system to support this structure, and automatic migration for existing setups, ensuring a smooth transition for all users. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
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
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- In
migrateConfig, the early-return check only verifies thatACTIVE_DOMAINis notundefinedandDOMAINSis an array, which means a partially-written or corrupted new-format config (e.g.ACTIVE_DOMAINset but missing/emptyDOMAINS) will skip migration and then cause runtime errors ingetActiveDomainConfig; consider tightening this guard (e.g. also ensuring there is a matching domain forACTIVE_DOMAIN) or falling back to a safe default migration whenDOMAINSis missing or does not contain the active domain.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `migrateConfig`, the early-return check only verifies that `ACTIVE_DOMAIN` is not `undefined` and `DOMAINS` is an array, which means a partially-written or corrupted new-format config (e.g. `ACTIVE_DOMAIN` set but missing/empty `DOMAINS`) will skip migration and then cause runtime errors in `getActiveDomainConfig`; consider tightening this guard (e.g. also ensuring there is a matching domain for `ACTIVE_DOMAIN`) or falling back to a safe default migration when `DOMAINS` is missing or does not contain the active domain.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request introduces a robust multidomain support system, allowing the CLI to manage multiple environment configurations seamlessly. The inclusion of an automatic migration path for existing single-domain setups is a thoughtful touch for backward compatibility. The transition to English for CLI descriptions and internal documentation is also a positive step for broader usability. I have identified a few areas for improvement, primarily focused on ensuring data integrity during migration, maintaining consistency in domain naming, and reducing code duplication for better maintainability.
| const existingValues = {}; | ||
| for (const key of DOMAIN_CONFIG_KEYS) { | ||
| if (store[key] !== undefined) { | ||
| existingValues[key] = store[key]; | ||
| } | ||
| } | ||
|
|
||
| // Create default domain: defaults + any existing overrides | ||
| const defaultDomain = { | ||
| DOMAIN_NAME: 'default', | ||
| ...DEFAULT_DOMAIN_CONFIG, | ||
| ...existingValues | ||
| }; | ||
|
|
||
| // Clear old keys and set new format via conf API | ||
| for (const key of DOMAIN_CONFIG_KEYS) { | ||
| config.delete(key); | ||
| } |
There was a problem hiding this comment.
The migration logic currently only preserves known configuration keys. Any custom keys previously set by users (e.g., via wf config set CUSTOM_KEY value) will be lost during migration because they are neither moved into the new default domain object nor deleted from the root (where they are no longer accessible by the new domain-aware get() logic). It is recommended to migrate all existing keys from the root store to the default domain.
References
- Ensure data integrity during configuration migrations by preserving user-defined custom keys.
| function addDomain(name, options) { | ||
| const domains = config.get('DOMAINS') || []; | ||
|
|
||
| if (domains.find(d => d.DOMAIN_NAME === name)) { | ||
| throw new Error(`Domain "${name}" already exists.`); | ||
| } | ||
|
|
||
| // Use default domain as base, fall back to DEFAULT_DOMAIN_CONFIG | ||
| const defaultDomain = domains.find(d => d.DOMAIN_NAME === 'default'); | ||
| const base = defaultDomain | ||
| ? { ...defaultDomain } | ||
| : { ...DEFAULT_DOMAIN_CONFIG }; | ||
| delete base.DOMAIN_NAME; | ||
|
|
||
| const newDomain = { | ||
| DOMAIN_NAME: name, |
There was a problem hiding this comment.
Domain names are currently handled case-sensitively. This allows for the creation of confusingly similar domains (e.g., 'default' and 'Default') and may lead to unexpected behavior when using commands like wf domain use or wf domain remove if the user doesn't match the case exactly. Normalizing domain names to lowercase during creation and lookup would improve consistency.
References
- Normalize identifiers like domain names to ensure consistent behavior across CLI commands.
| const VALID_KEYS = [ | ||
| 'API_BASE_URL', 'API_VERSION', 'DB_HOST', 'DB_PORT', 'DB_NAME', | ||
| 'DB_USER', 'DB_PASSWORD', 'AUTO_DISCOVER', 'USE_DOCKER', | ||
| 'DOCKER_POSTGRES_CONTAINER', 'DEBUG_MODE' | ||
| ]; |
There was a problem hiding this comment.
The VALID_KEYS array duplicates the configuration keys already defined in src/lib/config.js. This creates a maintenance burden as any new configuration setting must be manually added to both files. Since DEFAULT_DOMAIN_CONFIG is already exported from the config library, you can derive these keys dynamically.
References
- Avoid hardcoding duplicate lists of configuration keys to improve maintainability.
3 participants
Summary by Sourcery
Add multidomain configuration support to the CLI and migrate existing single-domain configs to a new domain-aware format.
New Features:
Enhancements:
Documentation: