Add 'create' command for modules with optional fields#3
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 14 minutes and 17 seconds. ⌛ 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. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughAdds a new Changes
Sequence DiagramsequenceDiagram
participant User as User
participant CLI as CLI Handler
participant Validator as Project Validator
participant Resolver as Member Resolver
participant API as Projects API
User->>CLI: plane modules create --name "Sprint 3" --lead "Alice" --status in_progress --start-date 2026-03-01
CLI->>Validator: resolve project id & check feature "module_view"
Validator-->>CLI: feature enabled
CLI->>Resolver: getMemberId("Alice")
Resolver-->>CLI: return member id (mem1)
CLI->>CLI: validate dates, normalize status "in_progress" → "in-progress"
CLI->>API: POST /projects/{id}/modules {name, status, description?, start_date?, target_date?, lead: mem1}
API-->>CLI: 201 {id, name, ...}
CLI-->>User: log "Created module: Sprint 3 (<id>)"
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
tests/modules.test.ts (1)
163-263: Add one parser-level test forplane modules create.These cases call
modulesCreateHandlerdirectly, so they won't catch regressions in the public CLI wiring—e.g. thecreatesubcommand registration or the--start-date/--target-datemapping intostartDate/targetDate. One test throughmodulesCreateorcliwould cover the actual entrypoint this PR adds.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/modules.test.ts` around lines 163 - 263, Add a parser-level test that exercises the public entrypoint instead of calling modulesCreateHandler directly: invoke the CLI entry (modulesCreate or cli command) with arguments equivalent to "plane modules create --project ACME --name 'Design System Rollout' --description 'Ship tokens and docs' --status in_progress --start-date 2026-04-01 --target-date 2026-04-30 --lead 'Jane Doe'" so the test verifies the flag-to-field mapping (startDate/targetDate) and lead resolution end-to-end; locate the test harness near the existing modulesCreateHandler tests and assert the HTTP request body and console output like the existing expectations (postedBody contains start_date/target_date and lead resolved to mem1, logs contain "Created module...").src/commands/modules.ts (1)
59-65: Validate--start-dateand--target-datebefore posting.Both flags are documented as
YYYY-MM-DD, but any string is forwarded to the API right now. A small CLI-side check here would fail fast and keep simple input typos from turning into backend-only errors.Also applies to: 153-157
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/commands/modules.ts` around lines 59 - 65, The start-date and target-date option definitions (startDateOption and targetDateOption) currently accept any string; add a CLI-side validation step in their Options pipeline to enforce the YYYY-MM-DD pattern (e.g., strict regex like /^\d{4}-\d{2}-\d{2}$/ and/or attempt a Date parse to ensure valid month/day) and return a user-facing validation error if it fails; apply the same validation to the duplicate option definitions later in the file (the ones around lines 153–157) so both places reject invalid dates before calling the API, and ensure the validation message clearly references the offending flag name.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/commands/modules.ts`:
- Around line 59-65: The start-date and target-date option definitions
(startDateOption and targetDateOption) currently accept any string; add a
CLI-side validation step in their Options pipeline to enforce the YYYY-MM-DD
pattern (e.g., strict regex like /^\d{4}-\d{2}-\d{2}$/ and/or attempt a Date
parse to ensure valid month/day) and return a user-facing validation error if it
fails; apply the same validation to the duplicate option definitions later in
the file (the ones around lines 153–157) so both places reject invalid dates
before calling the API, and ensure the validation message clearly references the
offending flag name.
In `@tests/modules.test.ts`:
- Around line 163-263: Add a parser-level test that exercises the public
entrypoint instead of calling modulesCreateHandler directly: invoke the CLI
entry (modulesCreate or cli command) with arguments equivalent to "plane modules
create --project ACME --name 'Design System Rollout' --description 'Ship tokens
and docs' --status in_progress --start-date 2026-04-01 --target-date 2026-04-30
--lead 'Jane Doe'" so the test verifies the flag-to-field mapping
(startDate/targetDate) and lead resolution end-to-end; locate the test harness
near the existing modulesCreateHandler tests and assert the HTTP request body
and console output like the existing expectations (postedBody contains
start_date/target_date and lead resolved to mem1, logs contain "Created
module...").
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0b7f518e-76df-4cb4-98e7-4e11edf11088
📒 Files selected for processing (7)
CHANGELOG.mdREADME.mdSKILL.mdsrc/app.tssrc/commands/modules.tssrc/config.tstests/modules.test.ts
There was a problem hiding this comment.
🧹 Nitpick comments (2)
src/commands/labels.ts (1)
72-80: Consider usingOption.Option<string>for type consistency.The
colorparameter uses a raw tagged union type{ _tag: "Some"; value: string } | { _tag: "None" }while other handlers in this PR (e.g.,modulesCreateHandler,pagesCreateHandler) useOption.Option<string>. Using the Effect type alias would be more consistent and provide better type safety.♻️ Suggested change
export function labelsCreateHandler({ project, name, color, }: { project: string; name: string; - color: { _tag: "Some"; value: string } | { _tag: "None" }; + color: Option.Option<string>; }) { return Effect.gen(function* () { const { id } = yield* resolveProject(project); interface LabelPayload { name: string; color?: string; } const body: LabelPayload = { name }; - if (color._tag === "Some") body.color = color.value; + if (Option.isSome(color)) body.color = color.value;You'll also need to import
Optionfromeffect:-import { Console, Effect } from "effect"; +import { Console, Effect, Option } from "effect";🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/commands/labels.ts` around lines 72 - 80, Change the color parameter of labelsCreateHandler to use the Effect Option type for consistency and safety: replace the raw tagged-union type on the color parameter with Option.Option<string> and add an import for Option from 'effect'; update the function signature for labelsCreateHandler and any call sites within this diff to accept Option.Option<string> instead of the manual { _tag: "Some" | "None" } union.src/commands/modules.ts (1)
59-65: Consider validating date format before API call.The options describe
YYYY-MM-DDformat, but no validation is performed. Invalid dates will be passed to the API, which may reject them with a less helpful error message. Consider adding client-side validation for better UX.♻️ Optional validation helper
+function validateDateFormat(date: string, fieldName: string): Effect.Effect<string, Error> { + if (!/^\d{4}-\d{2}-\d{2}$/.test(date)) { + return Effect.fail(new Error(`${fieldName} must be in YYYY-MM-DD format`)); + } + return Effect.succeed(date); +}Then in
modulesCreateHandler:if (Option.isSome(startDate)) { - body.start_date = startDate.value; + body.start_date = yield* validateDateFormat(startDate.value, "--start-date"); } if (Option.isSome(targetDate)) { - body.target_date = targetDate.value; + body.target_date = yield* validateDateFormat(targetDate.value, "--target-date"); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/commands/modules.ts` around lines 59 - 65, The startDateOption and targetDateOption declare a YYYY-MM-DD format but lack validation, so add client-side validation (e.g., regex /^\d{4}-\d{2}-\d{2}$/ plus a semantic check for valid month/day or Date parsing) before calling the API in modulesCreateHandler: validate the parsed option values, return a user-friendly error if the format or date is invalid, and only proceed to build the API payload when both startDateOption and targetDateOption pass validation; reference the option names (startDateOption, targetDateOption) and the handler (modulesCreateHandler) when adding the checks.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/commands/labels.ts`:
- Around line 72-80: Change the color parameter of labelsCreateHandler to use
the Effect Option type for consistency and safety: replace the raw tagged-union
type on the color parameter with Option.Option<string> and add an import for
Option from 'effect'; update the function signature for labelsCreateHandler and
any call sites within this diff to accept Option.Option<string> instead of the
manual { _tag: "Some" | "None" } union.
In `@src/commands/modules.ts`:
- Around line 59-65: The startDateOption and targetDateOption declare a
YYYY-MM-DD format but lack validation, so add client-side validation (e.g.,
regex /^\d{4}-\d{2}-\d{2}$/ plus a semantic check for valid month/day or Date
parsing) before calling the API in modulesCreateHandler: validate the parsed
option values, return a user-friendly error if the format or date is invalid,
and only proceed to build the API payload when both startDateOption and
targetDateOption pass validation; reference the option names (startDateOption,
targetDateOption) and the handler (modulesCreateHandler) when adding the checks.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a0de6ea6-77e3-4ab5-b7b9-1e797ff86a65
📒 Files selected for processing (9)
CHANGELOG.mdREADME.mdSKILL.mdsrc/app.tssrc/commands/issue.tssrc/commands/labels.tssrc/commands/modules.tssrc/commands/pages.tstests/issue-commands.test.ts
✅ Files skipped from review due to trivial changes (2)
- src/app.ts
- SKILL.md
🚧 Files skipped from review as they are similar to previous changes (1)
- CHANGELOG.md
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/commands/modules.ts (1)
179-193: Add a cross-field guard for start/target date ordering.Both dates are validated independently, but
--target-datecan still be earlier than--start-date. Adding a local check will give users a faster, clearer error.Suggested patch
if (Option.isSome(targetDate)) { body.target_date = yield* validateModuleDateInput( targetDate.value, "--target-date", ); } + if ( + body.start_date !== undefined && + body.target_date !== undefined && + body.target_date < body.start_date + ) { + return yield* Effect.fail( + new Error("--target-date must be on or after --start-date"), + ); + } if (Option.isSome(lead)) { body.lead = yield* getMemberId(lead.value); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/commands/modules.ts` around lines 179 - 193, After independently validating startDate and targetDate using validateModuleDateInput and assigning to body.start_date and body.target_date, add a cross-field guard that, when both Option.isSome(startDate) and Option.isSome(targetDate) are present, compares the parsed dates (body.start_date and body.target_date) and throws/returns a clear user-facing error if body.target_date is earlier than body.start_date; update the code around the startDate/targetDate handling in modules.ts (the Option.isSome(startDate)/Option.isSome(targetDate) blocks) to perform this check immediately after both assignments so users receive a fast, descriptive validation error.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/commands/modules.ts`:
- Around line 179-193: After independently validating startDate and targetDate
using validateModuleDateInput and assigning to body.start_date and
body.target_date, add a cross-field guard that, when both
Option.isSome(startDate) and Option.isSome(targetDate) are present, compares the
parsed dates (body.start_date and body.target_date) and throws/returns a clear
user-facing error if body.target_date is earlier than body.start_date; update
the code around the startDate/targetDate handling in modules.ts (the
Option.isSome(startDate)/Option.isSome(targetDate) blocks) to perform this check
immediately after both assignments so users receive a fast, descriptive
validation error.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d8b7ced9-7fc5-4cec-8942-94d6a861e9c0
📒 Files selected for processing (3)
src/commands/labels.tssrc/commands/modules.tstests/modules.test.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- tests/modules.test.ts
…import prompt details
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/project-agents.ts`:
- Around line 148-153: hasSkillSectionInAgentsFile currently returns true when
only SKILL_SECTION_START is present, which allows malformed files to get
duplicated sections; update the function (referencing
hasSkillSectionInAgentsFile, SKILL_SECTION_START, and SKILL_SECTION_END) to
detect the presence of both delimiters before returning true (e.g., require
content.includes(SKILL_SECTION_START) && content.includes(SKILL_SECTION_END) or
equivalent regex), so upsert/replacement logic only runs when a complete skill
section exists.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4a416c36-e671-4f1c-9b13-8c5fdb9db680
📒 Files selected for processing (7)
.github/ISSUE_TEMPLATE/config.ymlCHANGELOG.mdREADME.mdpackage.jsonsrc/commands/init.tssrc/project-agents.tstests/project-features.test.ts
✅ Files skipped from review due to trivial changes (2)
- .github/ISSUE_TEMPLATE/config.yml
- package.json
🚧 Files skipped from review as they are similar to previous changes (1)
- CHANGELOG.md
Summary
Introduce a new command to create modules with optional fields such as description, status, start date, target date, and lead. This enhancement allows users to manage modules more flexibly and efficiently.
Related Issue
No public tracking item was needed.
Changes
plane modules createcommand with optional parameters.Validation
bun run typecheckbun testcoverage for the touched areabun run check:allif shared command behavior, schemas, or output changedDocs
README.mdupdated if CLI usage changedSKILL.mdupdated if AI-agent usage changedCHANGELOG.mdupdated if there is a notable user-facing changeRisks Or Follow-Ups
Summary by CodeRabbit
New Features
plane modules createto create modules with optional description, status, dates, and lead (accepts display name, email, or UUID); status inputs are normalized.plane init --localcan now prompt to import the SKILL guide into AGENTS.md and updates that section idempotently.Behavior Changes
issue create,labels create,modules create, andpages createnow prefer named flags (--title/--name), letting PROJECT be omitted to use the saved project.Documentation
Tests