feat(cli): Add interactive prompts for commands

[agusayerza]

This PR improves the CLI's user experience by introducing an interactive mode for the create, dryrun, deploy, and init commands.
​
When a user runs one of these commands without providing all the required arguments, the CLI will now launch an interactive prompt to guide them through the missing options. This makes the CLI easier to use, as it no longer requires users to memorize all command-line arguments.
​
The interactive prompts are built using inquirer to provide a user-friendly selection list for known values (like function types or environments).
​
The interactive mode is enabled by default and can be disabled with the --no-interactive flag or by setting the CI environment variable, ensuring backward compatibility and scriptability.
​
Fixes NAN-4237
​
Testing:

1. Run npm install to add the new inquirer dependency.
2. Run nango create without any arguments. Verify that you are prompted to select a function type, integration, and provide a name.
3. Run nango dryrun without any arguments. Verify that you are prompted to select an environment, a function, and a connection.
4. Run nango deploy without an environment. Verify that you are prompted to select one.
5. Run nango init without a path. Verify that you are prompted to enter one.
6. Run any of the above commands with the --no-interactive flag to confirm that the prompts are skipped and the command fails due to missing arguments.

---

A shared Ensure utility now orchestrates the interactive prompts, translating missing-argument errors into actionable guidance while preserving non-interactive execution when required.

Affected Areas

• packages/cli/lib/index.ts
• packages/cli/lib/services/interactive.service.ts
• packages/cli/lib/services/ensure.service.ts
• packages/cli/lib/services/function-create.service.ts
• packages/cli/lib/types.ts
• packages/cli/lib/services/sdk.ts
• packages/cli/lib/utils/errors.ts
• packages/cli/tsconfig.json
• packages/cli/package.json
• docs/reference/cli.mdx
• package-lock.json

---

This summary was automatically generated by @propel-code-bot

[linear]

NAN-4237 CLI Interactivity and Cleanup

[my-senior-dev-pr-review]

🤖 My Senior Dev — Analysis Complete

👤 For @agusayerza

📁 Expert in packages/ (16 edits) • ⚡ 3rd PR this month

View your contributor analytics →

---

📊 13 files reviewed • 10 need attention

⚠️ Needs Attention:

• packages/cli/lib/index.ts — Changes to command execution and interactive behavior raise security and logic concerns.
• packages/cli/lib/services/ensure.service.ts — This service manages user prompt interactions and has potential security risks if user inputs are not validated.
• +2 more concerns...

---

🚀 Open Interactive Review →

The full interface unlocks features not available in GitHub:

• 💬 AI Chat — Ask questions on any file, get context-aware answers
• 🔍 Smart Hovers — See symbol definitions and usage without leaving the diff
• 📚 Code Archeology — Understand how files evolved over time (/archeology)
• 🎯 Learning Insights — See how this PR compares to similar changes

---

💬 Chat here: @my-senior-dev explain this change — or try @chaos-monkey @security-auditor @optimizer @skeptic @junior-dev

📖 View all 12 personas & slash commands

You can interact with me by mentioning @my-senior-dev in any comment:

In PR comments or on any line of code:

• Ask questions about the code or PR
• Request explanations of specific changes
• Get suggestions for improvements

Slash commands:

• /help — Show all available commands
• /archeology — See the history and evolution of changed files
• /profile — Performance analysis and suggestions
• /expertise — Find who knows this code best
• /personas — List all available AI personas

AI Personas (mention to get their perspective):

Persona	Focus
@chaos-monkey 🐵	Edge cases & failure scenarios
@skeptic 🤨	Challenge assumptions
@optimizer ⚡	Performance & efficiency
@security-auditor 🔒	Security vulnerabilities
@accessibility-advocate ♿	Inclusive design
@junior-dev 🌱	Simple explanations
@tech-debt-collector 💳	Code quality & shortcuts
@ux-champion 🎨	User experience
@devops-engineer 🚀	Deployment & scaling
@documentation-nazi 📚	Documentation gaps
@legacy-whisperer 🏛️	Working with existing code
@test-driven-purist ✅	Testing & TDD

For the best experience, view this PR on myseniordev.com — includes AI chat, file annotations, and interactive reviews.

[TBonnin]

would it make sense to pass the integrations as argument and move the the parsing/loading outside of the interactive logic? Same for fetching the connections below?

[agusayerza]

Done. I moved the parsing logic out and just pass the list to the prompt function now

[TBonnin]

why not fetching the environments from the API?

[agusayerza]

Checked the API and there is no endpoint to list environments yet, maybe I missed it? I talked with Bastien of this being a fast-follow-up

[agusayerza]

Just checked the code, endpoint exists but not documented or exposed on the SDK. My bad. I still think this is an improvement to be done as a fast-follow-up

[TBonnin]

not sure I understand why --no-interactive is true by default if we want the interactive mode enabled by default

[agusayerza]

--no prefix on commander sets the flag to false when you pass it instead of true. Added a better description to the comment to explain that weird behaviour

[TBonnin]

where is projecPath being used?

[agusayerza]

Good catch. It's being used now to resolve the absolute path, missed it

[TBonnin]

I feel like extracting this logic in its own file/class with functions and early returns will reduce the branching, make it easier to read and more testable as well as reusable in the different commands. Something like that:

export class Ensure {
    constructor(private readonly interactive: boolean)

    private async ensure<T>(
      currentValue: T | undefined,
      promptFn: () => Promise<T>,
      errorMessage: string
  ): Promise<T> {
      if (currentValue) return currentValue;
      if (!interactive) throw new MissingArgumentError(errorMessage);
      try {
      return await promptFn();
      catch {
           // show error and process exit
      }
  }

  public async functionType(
      sync: boolean,
      action: boolean,
      onEvent: boolean,
  ): Promise<FunctionType> {
      if (sync) return 'sync';
      if (action) return 'action';
      if (onEvent) return 'on-event';

      if (!this.interactive) {
          throw new MissingArgumentError('Must specify --sync, --action, or --on-event');
      }

      return await promptForFunctionType();
  }

  public async integration(
      current: string | undefined,
      context: { fullPath?: string; isNangoFolder: boolean; isZeroYaml:
  boolean; debug?: boolean }
  ): Promise<string> {
      return ensure(
          current,
          () => promptForIntegrationName(context),
          'Integration name is required'
      );
  }

  public async functionName(
      current: string | undefined,
      functionType: FunctionType,
  ): Promise<string> {
      return ensure(
          current,
          () => promptForFunctionName(functionType),
          'Function name is required'
      );
  }

  export async function environment(
      current: string | undefined,
      interactive: boolean
  ): Promise<string> {
      return ensure(
          current,
          interactive,
          () => promptForEnvironment(),
          'Environment is required'
      );
  }

  public async function(
      current: string | undefined,
      availableFunctions: { name: string; type: string }[]
  ): Promise<string> {
      return ensure(
          current,
          () => promptForFunctionToRun(availableFunctions),
          'Function name is required'
      );
  }

  public async connection(
      current: string | undefined,
      environment: string
  ): Promise<string> {
      return ensure(
          current,
          () => promptForConnection(environment),
          'Connection ID is required'
      );
  }

  public async projectPath(
      current: string | undefined,
  ): Promise<string> {
      return ensure(
          current,
          () => promptForProjectPath(),
          'Project path is required'
      );
  }

so it can be used like this

const ensure = new Ensure(interactive)
const functionType = await ensure.functionType(sync, action,
  onEvent);
integration = await ensure.integration(integration, { ... });
name = await ensure.functionName(name, functionType);

wdyt?

[agusayerza]

Great suggestion, implemented it

[TBonnin]

can we add some info about how users could fix the issue?

[agusayerza]

Added a hint to use --no-interactive if the prompt fails (I would expect this to happen in CI/non-TTY).

[TBonnin]

we always pin to a specific version. We have all collectively been burned too many time by breaking changes (even in patch version)

[agusayerza]

Good call, pinned it

[agusayerza]

Thoughts on if this should be a minor or a patch? Sticking to strict semver its a minor, but open to change it if anyone thinks its a patch

[TBonnin]

is it a breaking change? aka: does it modify the behavior of existing commands? if yes, minor otherwise patch

[TBonnin]

version isn't managed by modifying the package.json directly. The release workflow takes care of it

[marcindobry]

There is also packages/cli/lib/utils/errors.ts. Can we unify them?

[agusayerza]

Missed that file, will merge them

[marcindobry]

ooc: Why do we need to import .js files here?

[agusayerza]

ESM modules require file extension on imports. Addtionally, my understanding is that typescript doesn't change file extensions when transpiling to javascript, so we need to reference the js files.

Might be wrong and there is another reason why this is done, but I think this is the case

[marcindobry]

When would this be used in a CI environment?

I'm not sure it's a great idea to have the completely opposite behavior of a flag in CI instead of outside of it. Would it make more sense to raise an error in CI environment and make sure people specify --no-interactive instead? This would be a breaking change, though, hence the question above :P

[agusayerza]

Some customers use the CLI today on CI envs to test and deploy nango. If we force them to adopt the --no-interactive flag we would break their CI pipelines. At the same time, we want interactive mode to be the default use case for people using the CLI on the terminal, so this gets both things done. A warning for CI envs that do not provide the --no-interactive flag might be in order though. Wdyt?

[marcindobry]

Yup I think a warning would be great.

[propel-code-bot]

[Documentation] Fix subject-verb agreement: "Destructive changes ... requires" should be "Destructive changes ... require".

Context for Agents

[**Documentation**]

Fix subject-verb agreement: "Destructive changes ... requires" should be "Destructive changes ... require".

File: docs/reference/cli.mdx
Line: 106

[TBonnin]

lgtm. Just the package version and dependency pinning and the rest is good to go I think

[TBonnin]

pin, pin, pin

[agusayerza]

🤦

[TBonnin]

does interactive and ensure belongs to the services folder? You are gonna ask what's a service in the context of the CLI and to be honest I am not sure I have an good answer :/

[agusayerza]

I just followed suit, but it doesn't make any sense. Thought of it as just where the main logic leaves, but it is a bit a weird naming scheme if you ask me

[TBonnin]

you don't need to change anything here. Let's keep it in mind though when/if we refactor the CLI ;)