[sentry-junior]

Refs #1564. This is the first slice: the mechanism plus five commands.

A [<org>/][<project>] positional now owns both parsing and resolution. The command picks a parser from src/lib/target-positional.ts, and that parser comes with its resolver:

parse: orgOptionalTarget,                    // resolveOrgOptionalTarget
parse: projectBoundTarget,                   // resolveProjectBoundTarget
parse: orgProjectTarget(resolveViewTargets), // command-specific resolver

func gets a LazyPositional with three members: target.parsed (the ParsedOrgProject), target.resolved (a promise of the resolver's result), and target.raw (what the user typed):

async *func(this: SentryContext, flags: ListFlags, target: OrgOptionalTarget) {
  const resolved = await target.resolved;

func never calls parseOrgProjectArg or a resolver, never picks which resolver to use, and needs no default for an omitted target. An omitted optional target arrives as auto-detect. project view moves its target switch into resolveViewTargets and reads target.parsed.type.

• No command names to pass. Resolvers read the command path from this.commandPrefix, which Stricli's forCommand sets and the SDK invoker now sets from its command path. The COMMAND_NAME constants these commands used are gone. A context without commandPrefix makes resolution throw rather than print a hint with a blank command name; test mock contexts set it.
• Destructive commands guard automatically. buildDeleteCommand calls markDestructive on its lazy positionals, and the target resolver then runs requireExplicitTarget. project delete uses plain projectBoundTarget. Once docs(cli): Generate and check docs that mirror CLI behavior #1626's destructive flag lands, the call can move into buildCommand so issue merge and trial start get it too.
• Lint rule. sentry-cli/require-target-resolution fails a command function that takes OrgOptionalTarget, ProjectBoundTarget or OrgProjectTarget<R> but never reads .resolved, since skipping it skips the resolver and the destructive guard.

When things run. Both steps are lazy (LazyPositional in src/lib/positional-parse.ts, a plain class with memoized getters). The parse runs on the first parsed read and the resolver on the first resolved read; each runs once. Both happen inside func, so the order matches main:

• The auth guard and rc URL check run first. A bad target with no login still reports "Not authenticated" (exit 10).
• Parse errors keep their CliError semantics. sentry project view @latest exits 21 with the ValidationError, not Stricli's Failed to parse … (exit -4). A parse error also rejects resolved.
• parseOrgProjectArg's URL side effect still runs after those checks. For a pasted Sentry URL it calls applySentryUrlContext, which can switch SENTRY_URL/SENTRY_HOST, save that host as the default, or throw HostScopeError. Running it at Stricli scan time would have let the auth guard and rc URL check run against the host taken from the URL.

Resolution stays a promise because resolvers need auth, config, DSN detection, and API calls. Shared code that handles any positional (buildListCommand's plural-alias interception, help recovery, setArgsContext) reads the raw input with rawPositional(value), an instanceof LazyPositional check. Stricli calls parsers with the command context as this; the resolver gets that context plus commandName.

Callers that skip Stricli. The typed SDK (buildInvoker) and tests that call command.loader() pass raw strings. buildCommand runs applyLazyPositionals on them, and on omitted optional positionals, so every caller keeps passing what the user typed and func always gets the same shape. When plural-alias interception drops the target, buildListCommand runs it again so the dropped target becomes auto-detect. sdk.project.view({ orgProject: "@latest" }) is rejected instead of silently auto-detecting. The SDK invoker also sets directInvoke, which turns off help positional recovery: a failing SDK call whose target is help throws its error, as on main, instead of returning help text.

Shell completion is unchanged. Completion kinds come from a tag on the parser (withCompletionTarget), shared with parseOrgTarget and parseOrgProjectTarget. The generated targets file matches main.

Migrated: trace list, replay list, feedback list, project view, project delete.

Not in this PR:

• LIST_TARGET_POSITIONAL / buildOrgListCommand. feat(cli): Name filter for project, team, repo, monitor and integration lists #1575 (splitListTargetAndFilter) reads the raw target and splits it before parsing (for example acme/web-*). These should move after it lands, using target.raw.
• Issue and dashboard positionals. feat(cli): Complete issue short IDs and dashboards in shell completion #1572 adds parseIssueTarget / parseDashboardTarget in the same files. When one of the two PRs rebases, its parsers should switch from the PARSER_TARGETS map to withCompletionTarget.
• [<org>/<project>/]<id> positionals (trace view, span list, event view, log view, …). Stricli parses each argument on its own, but what each one means depends on how many were given. Those keep parsing in func.
• Release org/version positionals. They already share resolveReleaseTarget.

via BYK.

--

View Junior Session [Sentry]

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Oct 23, 2026 4:45pm UTC

[BYK]

Not really a fan of the two-stage parsing. I do understand the benefits but I was hoping to find a way to avoid the in-func resolve or parse call.

Also I'd love to make tests use the applyPositionalParsers or something like that rather than repeating the resolver/parser calls over and over.

[BYK]

What's the URL side effect you keep mentioning with the new approach and what are the dangers/gotchas of it?

[BYK]

Okay looking much better!

[BYK]

This is HOT HOT HOT 🔥