deno support

[prayanshchh]

Adds experimental support for running Encore TS apps on Deno, following the existing Bun support.

Runtime: a new deno-runtime experiment starts the app with deno run --allow-all. Enabling both bun-runtime and deno-runtime is an error.

Package manager: "packageManager": "deno@x" in package.json uses deno install and runs tests with deno task test.

inspired from:

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

Summary by CodeRabbit

• New Features
  • Added Deno as a supported runtime for TypeScript applications, including dependency installation and test execution through Deno.
  • Deno production builds now use production-only dependency installation, and Deno entrypoints run with all permissions enabled.
  • Builds now report an error if both Bun and Deno runtimes are selected; Node.js remains the default when neither is selected.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: QUIET
• Plan: Advanced
• Run ID: 38e59fd7-bdcf-43d1-ba8a-98245951200a

---

📥 Commits

Reviewing files that changed from the base of the PR and between 520df48 and 1e91ae5.

---

📒 Files selected for processing (6)

• runtimes/go/appruntime/exported/experiments/names.go
• tsparser/src/builder/mod.rs
• tsparser/src/builder/package_mgmt.rs
• tsparser/src/builder/transpiler.rs
• tsparser/tests/production_install.rs
• v2/tsbuilder/tsbuilder.go

---

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

---

Walkthrough

The builder now recognizes Deno as a Node.js runtime. It selects Deno through the deno-runtime experiment, installs packages with Deno, and launches entrypoints with --allow-all. Builds that enable both Bun and Deno experiments return an error.

Changes

Deno runtime support

Layer / File(s)	Summary
Experiment and runtime selection runtimes/go/appruntime/exported/experiments/names.go, tsparser/src/builder/mod.rs, v2/tsbuilder/tsbuilder.go	Adds the deno-runtime experiment and Deno runtime values. Compile selects Bun or Deno when its corresponding experiment is enabled, rejects builds with both enabled, and otherwise retains Node.js.
Package installation and launch tsparser/src/builder/package_mgmt.rs, tsparser/src/builder/transpiler.rs, tsparser/tests/production_install.rs	Adds Deno package-manager resolution and install behavior, including --prod for production installs. Deno test commands use deno task test, and Deno entrypoints launch with --allow-all. Tests include Deno in production and default install cases.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Compile as BuilderImpl.Compile
  participant Resolve as resolve_package_manager
  participant Manager as DenoPackageManager
  participant CLI as Deno
  Compile->>Resolve: select Deno runtime
  Resolve->>Manager: resolve deno manager
  Manager->>CLI: deno install, with --prod in production mode
  Compile->>CLI: launch entrypoint with --allow-all

Loading

Suggested reviewers: eandre

Merge Risk

Merge Risk: ⚪ Minimal · up to 1e91a

No actionable issue was identified that would prevent merging the experimental Deno support after normal checks.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 1e91a

Deno is explicitly opt-in and follows the existing fully privileged application-execution model. No new privilege escalation is established, but production runtime availability and isolation remain unverified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — Code executing in the selected Deno entrypoint is not contained by Deno permission checks. Its effective exposure is bounded by the application's execution identity and surrounding host or container controls, which were not established here. The emitted entrypoint may cover multiple services and gateways; host-wide or cross-tenant authority cannot be inferred from --allow-all alone.

Trust Boundaries and Controls

• observed — The runtime choice remains controlled by compilation experiments, and conflicting alternative runtimes are rejected before the compile request is sent. Deno receives the same generated-entrypoint command structure as Node/Bun rather than a new request-controlled command interface.

Resilience and Maintainability Implications

• inferred — The inherited manifest/tree consistency gap can leave the declared dependency version ahead of the installed contents after a failed update. This limits confidence in dependency-version enforcement, but no new security exposure or Deno-specific worsening was established by the base-to-head comparison.

Hardening Proposals

• proposed — Make the unrestricted Deno execution model explicit to users and validate runtime availability, native-module loading, and surrounding isolation before treating a deployment environment as supported. Narrower Deno permissions could be evaluated where compatible with the native runtime.

---

---

---

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly identifies the main change: adding Deno support across the runtime, package manager, and build configuration.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

---

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[prayanshchh]

bye bye deno :)