[GH-ISSUE #593] feat: Add opt-in extensions system (asc ext) #166

New issue

Closed

opened 2026-02-26 21:33:52 +03:00 by kerem · 1 comment

kerem commented

2026-02-26 21:33:52 +03:00

Owner

Originally created by @rudrankriyam on GitHub (Feb 17, 2026).
Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/593

Summary

Add an opt-in extension mechanism so teams can add custom commands without forking asc.

This should be designed with strong guardrails:

explicit invocation (no surprising command hijacking)
JSON-first inputs/outputs
no interactive prompts
safe by default

Why this matters

asc is already broad, but every team eventually wants a few custom workflows:

company-specific validation rules
custom notifications
glue code for internal systems

A lightweight extension system avoids:

long-lived forks
hard-to-upstream one-off features

Current state (verified)

No plugin/extension loading mechanism exists.
No ~/.asc/plugins or similar convention exists.

Proposed UX

Explicit extension entrypoint

asc ext run <name> [--] <args...>

Behavior:

Resolves an executable named asc-ext-<name> on PATH, or under ~/.asc/ext/.
Executes it as a subprocess.
Provides context via stdin/env vars (never via command-line args by default).

Passing context

stdin: JSON object, e.g.

{"ascVersion":"0.28.10","cwd":"...","args":["..."]}

env vars: ASC_APP_ID, ASC_DEFAULT_OUTPUT, etc. (existing behavior)

Output expectations

Extensions should print JSON by default.
asc ext run should optionally enforce JSON output:
- --expect-json (default true)

Management helpers (optional)

asc ext list
asc ext doctor

Constraints / non-goals

Do not auto-delegate unknown asc <cmd> to plugins (too risky / surprising).
Do not implement an interactive installer.
Keep it cross-platform.

Security notes

Never print secrets.
Avoid echoing full env in debug logs.
Consider a --sandbox/--allow-network model only if ever needed (probably out of scope).

Implementation notes

New command group: internal/cli/ext/.
Use exec.CommandContext.
Make resolution rules deterministic:
- exact filename match
- predictable search order
Provide clear errors for “not found” vs “not executable”.

Test plan (TDD-first)

cmdtests:
- ext run errors clearly when extension missing
- ext run executes a fixture script and captures output
- --expect-json rejects non-JSON output
unit tests:
- name validation (no path traversal)
- deterministic resolution order

Acceptance criteria

asc ext run exists and is self-documenting.
Explicit invocation only (no hijacking).
Deterministic resolution + safe defaults.
make test passes.

Originally created by @rudrankriyam on GitHub (Feb 17, 2026). Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/593 ## Summary Add an **opt-in** extension mechanism so teams can add custom commands without forking `asc`. This should be designed with strong guardrails: - explicit invocation (no surprising command hijacking) - JSON-first inputs/outputs - no interactive prompts - safe by default ## Why this matters `asc` is already broad, but every team eventually wants a few custom workflows: - company-specific validation rules - custom notifications - glue code for internal systems A lightweight extension system avoids: - long-lived forks - hard-to-upstream one-off features ## Current state (verified) - No plugin/extension loading mechanism exists. - No `~/.asc/plugins` or similar convention exists. ## Proposed UX ### Explicit extension entrypoint ```bash asc ext run <name> [--] <args...> ``` Behavior: - Resolves an executable named `asc-ext-<name>` on PATH, or under `~/.asc/ext/`. - Executes it as a subprocess. - Provides context via stdin/env vars (never via command-line args by default). ### Passing context - stdin: JSON object, e.g. ```json {"ascVersion":"0.28.10","cwd":"...","args":["..."]} ``` - env vars: `ASC_APP_ID`, `ASC_DEFAULT_OUTPUT`, etc. (existing behavior) ### Output expectations - Extensions should print JSON by default. - `asc ext run` should optionally enforce JSON output: - `--expect-json` (default true) ### Management helpers (optional) ```bash asc ext list asc ext doctor ``` ## Constraints / non-goals - Do **not** auto-delegate unknown `asc <cmd>` to plugins (too risky / surprising). - Do **not** implement an interactive installer. - Keep it cross-platform. ## Security notes - Never print secrets. - Avoid echoing full env in debug logs. - Consider a `--sandbox`/`--allow-network` model only if ever needed (probably out of scope). ## Implementation notes - New command group: `internal/cli/ext/`. - Use `exec.CommandContext`. - Make resolution rules deterministic: - exact filename match - predictable search order - Provide clear errors for “not found” vs “not executable”. ## Test plan (TDD-first) - [ ] cmdtests: - [ ] `ext run` errors clearly when extension missing - [ ] `ext run` executes a fixture script and captures output - [ ] `--expect-json` rejects non-JSON output - [ ] unit tests: - [ ] name validation (no path traversal) - [ ] deterministic resolution order ## Acceptance criteria - [ ] `asc ext run` exists and is self-documenting. - [ ] Explicit invocation only (no hijacking). - [ ] Deterministic resolution + safe defaults. - [ ] `make test` passes.

kerem

2026-02-26 21:33:52 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-26 21:33:53 +03:00

Author

Owner

@rudrankriyam commented on GitHub (Feb 20, 2026):

Closing this for now. The current workflow system already covers our immediate single-app use case, and we can revisit an opt-in extensions system later if there is clear demand from users/teams.

@rudrankriyam commented on GitHub (Feb 20, 2026): Closing this for now. The current workflow system already covers our immediate single-app use case, and we can revisit an opt-in extensions system later if there is clear demand from users/teams.

kerem referenced this issue

2026-02-26 21:34:38 +03:00

[PR #173] [MERGED] audit: minor code quality improvements #335