anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Discussion: Deno runtime as an alternative/complement to Bun #9453

New Issue
Open
opened 2026-02-16 18:12:29 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 18:12:29 -05:00
Owner
Copy Link
Copy Source

Originally created by @dennisrutjes-1 on GitHub (Feb 16, 2026).

Originally assigned to: @thdxr on GitHub.

Summary

Now that Deno 2.x has achieved full npm compatibility (package.json support, node_modules, CommonJS, Node built-in APIs), it's worth discussing whether OpenCode could benefit from Deno as an alternative or complementary runtime alongside Bun.

Why this is worth exploring

Security sandbox

Deno's permission system (--allow-read, --allow-net, --allow-run, --allow-write) could be genuinely valuable for a coding agent that executes arbitrary shell commands and modifies files. This would allow users to run OpenCode with fine-grained control over what it can access — something Bun doesn't offer at all.

For a tool that runs LLM-generated code and shell commands, built-in sandboxing seems like a natural fit.

Unified toolchain

Deno ships as a single binary that replaces: runtime + package manager + bundler + test runner + linter + formatter + type checker + LSP + doc generator + benchmarker. This could simplify OpenCode's dev setup and reduce devDependencies (e.g., Prettier could be replaced with deno fmt).

npm compatibility is no longer a blocker

Deno 2.x supports:

  • Full package.json support
  • node_modules (auto/manual modes)
  • CommonJS (require())
  • All Node built-in APIs via node: specifiers
  • Private npm registries
  • deno compile for single-binary distribution (like bun build --compile)
  • Native workspaces

Client/server architecture alignment

OpenCode's README highlights its client/server architecture. Deno's Web Standards alignment (native Fetch, Web Streams, URL, etc.) maps well to this design.

Where Bun still has an edge

To be fair about the trade-offs:

  • Startup speed: Bun is still ~2-3x faster on cold starts — matters for a CLI launched frequently
  • Turborepo integration: OpenCode's monorepo uses Turbo, which is well-tested with Bun but less so with Deno
  • Migration cost: 9,290 commits, 743 contributors — switching runtimes is a major undertaking
  • Bun-specific APIs: Any usage of Bun.serve(), Bun.file(), etc. would need rewriting

Proposal

This is not a "replace Bun with Deno" request — it's a discussion about whether:

  1. Deno compatibility could be added as a secondary supported runtime (some users may prefer it)
  2. Deno's security sandbox could be leveraged for safer execution of LLM-generated commands
  3. The project has any hard dependencies on Bun-specific APIs that would make this impractical

Context

Would love to hear the maintainers' thoughts on this. 🙏

Originally created by @dennisrutjes-1 on GitHub (Feb 16, 2026). Originally assigned to: @thdxr on GitHub. ## Summary Now that Deno 2.x has achieved full npm compatibility (package.json support, node_modules, CommonJS, Node built-in APIs), it's worth discussing whether OpenCode could benefit from Deno as an alternative or complementary runtime alongside Bun. ## Why this is worth exploring ### Security sandbox Deno's permission system (`--allow-read`, `--allow-net`, `--allow-run`, `--allow-write`) could be genuinely valuable for a coding agent that executes arbitrary shell commands and modifies files. This would allow users to run OpenCode with fine-grained control over what it can access — something Bun doesn't offer at all. For a tool that runs LLM-generated code and shell commands, built-in sandboxing seems like a natural fit. ### Unified toolchain Deno ships as a single binary that replaces: runtime + package manager + bundler + test runner + linter + formatter + type checker + LSP + doc generator + benchmarker. This could simplify OpenCode's dev setup and reduce devDependencies (e.g., Prettier could be replaced with `deno fmt`). ### npm compatibility is no longer a blocker Deno 2.x supports: - Full `package.json` support - `node_modules` (auto/manual modes) - CommonJS (`require()`) - All Node built-in APIs via `node:` specifiers - Private npm registries - `deno compile` for single-binary distribution (like `bun build --compile`) - Native workspaces ### Client/server architecture alignment OpenCode's README highlights its client/server architecture. Deno's Web Standards alignment (native Fetch, Web Streams, URL, etc.) maps well to this design. ## Where Bun still has an edge To be fair about the trade-offs: - **Startup speed**: Bun is still ~2-3x faster on cold starts — matters for a CLI launched frequently - **Turborepo integration**: OpenCode's monorepo uses Turbo, which is well-tested with Bun but less so with Deno - **Migration cost**: 9,290 commits, 743 contributors — switching runtimes is a major undertaking - **Bun-specific APIs**: Any usage of `Bun.serve()`, `Bun.file()`, etc. would need rewriting ## Proposal This is not a "replace Bun with Deno" request — it's a discussion about whether: 1. **Deno compatibility** could be added as a secondary supported runtime (some users may prefer it) 2. **Deno's security sandbox** could be leveraged for safer execution of LLM-generated commands 3. The project has any hard dependencies on Bun-specific APIs that would make this impractical ## Context - [Deno Node/npm compatibility docs](https://docs.deno.com/runtime/fundamentals/node/) - [Deno workspaces](https://docs.deno.com/runtime/fundamentals/workspaces/) - [deno compile](https://docs.deno.com/runtime/reference/cli/compile/) Would love to hear the maintainers' thoughts on this. 🙏
yindo commented 2026-02-16 18:12:29 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 16, 2026):

Thanks for the thoughtful discussion about Deno as a runtime alternative! While this raises interesting points about runtime security features, you may want to review these existing related discussions:

  • #12674: Implement isolated runtime sandboxing for code execution
  • #2242: Is there a way to sandbox the agent?
  • #9132: Official Docker Sandbox Template for code execution
  • #5529: Per-agent filesystem boundaries (allow/deny paths)

These issues explore various approaches to achieving the security and sandboxing benefits you're proposing. Feel free to cross-reference or consolidate discussions if they align with your proposal.

@github-actions[bot] commented on GitHub (Feb 16, 2026): Thanks for the thoughtful discussion about Deno as a runtime alternative! While this raises interesting points about runtime security features, you may want to review these existing related discussions: - #12674: Implement isolated runtime sandboxing for code execution - #2242: Is there a way to sandbox the agent? - #9132: Official Docker Sandbox Template for code execution - #5529: Per-agent filesystem boundaries (allow/deny paths) These issues explore various approaches to achieving the security and sandboxing benefits you're proposing. Feel free to cross-reference or consolidate discussions if they align with your proposal.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#9453
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?