Layer B tracking: Aspire Deno hosting (AddDenoApp / DenoAppResource)

[rickylabs]

Layer B tracking — Aspire Deno hosting (AddDenoApp / DenoAppResource)

Part of the Deno-on-Aspire dogfood proof (umbrella: #295). This issue tracks Layer B only, the
app-model hosting layer. It needs its own upstream tracking issue — microsoft/aspire#16218 is
Layer-A (CLI toolchain) scope, not hosting.

Feature

Fork rickylabs/aspire branch feat/deno-hosting-adddenoapp adds AddDenoApp / DenoAppResource to
Aspire.Hosting.JavaScript (the same assembly that ships AddBunApp). deno run -A;
WithDenoDefaults sets OTEL_DENO=true + WithOtlpExporter() (native OTel, zero app SDK);
deny-by-default perms; denoland/deno:2 single-stage publish, non-root deno user; VS Code
type:"deno" debug config; dev-cert trust; auto package-manager detection.

• Compare: microsoft/aspire@main...rickylabs:aspire:feat/deno-hosting-adddenoapp
• Upstream target: new tracking issue needed (hosting counterpart to #16218).
• Upstream PR body draft (review-ready, not filed): pr-body-layer-b.md.

Parity verdict vs community toolkit

CommunityToolkit.Aspire.Hosting.Deno (stable 13.4.0, ~62.8K downloads) hosts Deno as an
executable-on-PATH wrapper. Layer B covers 100% of its surface and adds native OTEL_DENO zero-SDK
telemetry, denoland/deno:2 publish, type:"deno" debug, and dev-cert trust — all provably absent
from the community package. Full matrix + verdict: aspire-deno-parity-and-motivation.md.

Open follow-ups (gaps to close before upstreaming)

• AddDenoTask-shaped ergonomic entry point (community exposes it as a distinct method).
• Document WithDeno(install: true) as the WithDenoPackageInstallation equivalent.
• OTEL_DENO is upstream-unstable — docs must carry the caveat; verify the flag against the
  pinned denoland/deno:2 tag.
• Complete Deno flag surface + composability + AddExecutable-replacement with tests (see Dogfood proof: Aspire Deno runtime (Layers A+B) verified against the full NetScript framework #295 ask S1: package quality — slow-types + docs (supervisor) — Waves 0–6 ✅ merged  #2).

Proof (dogfooded against NetScript)

Dogfood branch dogfood/aspire-deno-runtime (commit 75e4dea7) swaps NetScript services + plugins
onto AddDenoApp. Live boot: resource source=deno, appArgs=["run","-A","src/main.ts"],
Running/Healthy, GET /health 200; OTEL_DENO denoApp 3-var + fork-injected OTLP endpoint, zero
app-side OpenTelemetry SDK. Targeted harness cb2c3e98 — 12/12 PASS. Full scaffold.runtime E2E
(warm Docker, server 29.6.1, two runs): 11 passed / 1 failed — all 11 swap-relevant steps green
(scaffold init incl. apphost.mts type-check, 4 plugin installs, plugin list, aspire
restore/start/stop); the lone failure is database.init hitting the operation-runner's 900s cap,
which is swap-orthogonal: db init boots the AppHost in db-cli-mode short-circuit whose targets
come only from infrastructure.databases (never the swapped addDenoApp services/plugins), so it
exercises the untouched addExecutable DB path — the known pre-existing Prisma schema-engine
db-init flake (#98/#145), reproduced identically across both runs. Node-free proof: stack runs
entirely on Deno (node-free-proof.md).

Independence

Functionally standalone; merge after Layer A (Layer-A-first order). Does not require Layer A to build.

Guardrails

Evidence-only. Do NOT open the upstream Aspire PR without explicit user go.

[rickylabs]

Flag-surface + composability follow-up: DONE (fork rickylabs/aspire, branch feat/deno-hosting-adddenoapp, commit 6f6a2f079, local-only — not pushed).

Closed the two gaps from #295 ask #2:

• Complete Deno flag surface — 30 fluent methods on IResourceBuilder<DenoAppResource>: blanket + granular allow/deny perms (net/read/write/run/env/sys/ffi), config/import-map/lock/no-lock/node-modules-dir, unstable/watch/hmr, inspect/inspect-brk/inspect-wait, run/task/serve modes, and script-args + a WithDenoRuntimeArgs raw escape hatch. Emitted arg order is canonical-CLI regardless of call order (backed by a new DenoCommandLineAnnotation).
• AddExecutable-replacement — anything expressible as AddExecutable(name, "deno", ...) is now expressible via AddDenoApp + fluent methods; tri-state -A (default on, auto-dropped when a granular allow is set, or WithDenoAllowAll(false)). Backward compat preserved: bare AddDenoApp still emits deno run -A <entrypoint>.

Tests: dotnet test filtered to AddDenoAppTests — 35 passed / 0 failed (13 new). Docs: docs/deno-flag-surface.md lists the flags Aspire's resource model cannot safely express (fixed-list least-privilege net/env vs injected endpoints, deno serve port/host vs Aspire port allocation, manual inspect vs IDE debugger, watch in immutable containers, task-level perms belonging in deno.json).

Evidence-only; not pushed, no upstream PR.

[rickylabs]

Upstream PR opened: microsoft/aspire#18628 (Layer B — AddDenoApp / DenoAppResource hosting in Aspire.Hosting.JavaScript; new public API, maintainer API Review expected). Link: microsoft/aspire#18628