fix: correct profile name typo and init logic (#2542)#3221
fix: correct profile name typo and init logic (#2542)#3221deepshekhardas wants to merge 2 commits intotriggerdotdev:mainfrom
Conversation
The CommonCommandOptions Zod schema used .default(readAuthConfigCurrentProfileName()) which evaluates the default profile at module load time. When a user passes --profile <name>, the Zod schema already has the default value set and ignores the CLI argument. Changed to .optional().transform(v => v ?? readAuthConfigCurrentProfileName()) so the fallback is evaluated lazily at parse time, only when no --profile flag is provided. Fixes triggerdotdev#2542
|
|
Hi @deepshekhardas, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically. See https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md for more details. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
WalkthroughThis pull request corrects a typo in a constant name from Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 Tip CodeRabbit can use oxc to improve the quality of JavaScript and TypeScript code reviews.Add a configuration file to your project to customize how CodeRabbit runs oxc. |
| `npx trigger.dev@${cliTag} dev${options.profile && options.profile !== "default" ? ` --profile ${options.profile}` : "" | ||
| }` |
There was a problem hiding this comment.
🟡 Hardcoded "default" string instead of using DEFAULT_PROFILE constant
The new profile comparison on line 260 uses a hardcoded string "default" instead of importing and using the DEFAULT_PROFILE constant from packages/cli-v3/src/utilities/configFiles.ts:14. Every other comparison against the default profile name in the codebase uses the DEFAULT_PROFILE constant (e.g., packages/cli-v3/src/utilities/initialBanner.ts:18, packages/cli-v3/src/utilities/configFiles.ts:159). If the constant value were ever updated, this comparison would silently become inconsistent.
Prompt for agents
In packages/cli-v3/src/commands/init.ts, import DEFAULT_PROFILE from ../utilities/configFiles.js (add it to the existing import on line 42-44), then replace the hardcoded string "default" on line 260 with the DEFAULT_PROFILE constant:
Line 260 should change from:
options.profile && options.profile !== "default" ? ...
to:
options.profile && options.profile !== DEFAULT_PROFILE ? ...
Was this helpful? React with 👍 or 👎 to provide feedback.
| profile: z | ||
| .string() | ||
| .optional() | ||
| .transform((v) => v ?? readAuthConfigCurrentProfileName()), |
There was a problem hiding this comment.
🚩 Zod schema lazy evaluation partially defeated by eager Commander default
The Zod schema change at packages/cli-v3/src/cli/common.ts:16-19 defers the call to readAuthConfigCurrentProfileName() until parse time. However, the Commander option definition at packages/cli-v3/src/cli/common.ts:26 still eagerly calls readAuthConfigCurrentProfileName() during command configuration. When commands go through the normal Commander flow, Commander fills in the default before Zod parses the options, so the Zod transform's v ?? readAuthConfigCurrentProfileName() never triggers (since v is already a string from Commander). The lazy evaluation only benefits non-Commander code paths (e.g., direct calls to initCommand or other wrappers). This may or may not be the intended scope of the fix.
Was this helpful? React with 👍 or 👎 to provide feedback.
Corrects DEFFAULT_PROFILE typo and fixes Suggester logic for profile flag.