database link crashes: Unknown conflicting option "connectionString"

[heathweaver]

Summary

deno deploy database link crashes immediately with Unknown conflicting option "connectionString", making the command completely unusable in every form (flags, connection-string, and even --help).

Version

• @deno/deploy 0.0.99 (current latest on JSR)
• deno 2.8.3 (stable, x86_64-unknown-linux-gnu)

Reproduction

Any invocation of the subcommand crashes:

$ deno deploy database link --dry-run my-db --hostname db.example.com --port 5432 --username u --password p
$ deno deploy database link my-db "postgresql://u:p@host:5432/db"
$ deno deploy database link --help

All three produce:

error: Uncaught (in promise) Error: Unknown conflicting option "connectionString". Did you mean option "--config"?
    at https://jsr.io/@cliffy/flags/1.2.1/flags.ts:250:15
    ...
    at async https://jsr.io/@deno/deploy/0.0.99/main.ts:32:3

Root cause

In deploy/database.ts the link command declares the --hostname, --username, --password, and --port options as conflicts: ["connectionString"] (lines ~92–103), but connectionString is a positional argument, not an option:

.option("--hostname <string>", "...", { required: true, conflicts: ["connectionString"] })
.option("--username <string>", "...", { conflicts: ["connectionString"] })
.option("--password <string>", "...", { conflicts: ["connectionString"] })
.option("--port <number>",     "...", { conflicts: ["connectionString"] })
.arguments("<name:string> [connectionString:string]")

Cliffy's conflicts only accepts option names. Because connectionString is not an option, validation throws UnknownConflictingOptionError unconditionally, before any input is even processed — so the command can never run.

Impact

database link cannot be used from the CLI at all in 0.0.99. This blocks linking an external database (and the per-branch / per-timeline database workflow that depends on it) via the CLI; only the dashboard path works.

Suggested fix

Remove the four conflicts: ["connectionString"] entries. The action handler already implements the either/or behaviour (if (connectionString) { ...parse it... } else { ...use the flags... }), so the option/positional combination is already handled at runtime. If an explicit guard is desired, a manual check (if (connectionString && (options.hostname || options.port || ...)) throw ...) reproduces the intended mutual exclusion without misusing conflicts.

PR to follow.

[heathweaver]

While fixing this I found a second bug in the same command that blocks it even after the crash is resolved: port is sent to the backend as a string (expected number, received string), because cliffy's <number> is a value label rather than a type coercion. PR #105 fixes both, verified end-to-end with a real --dry-run against Postgres.