什么是 Deno？

此 Deno 技能提供了使用现代 Deno 运行时开发、测试和部署应用程序所需的技术专业知识。它专注于 Deno 独特的安全优先方法，帮助开发人员掌握细粒度的权限系统和基于模块的依赖模型。通过在 Openclaw Skills 中利用此技能，开发人员可以确保其 AI 代理正确处理 TypeScript 扩展、导入映射以及从 Node.js 环境的过渡。

该技能强调生产就绪 Deno 代码的最佳实践，例如避免过度开放的权限标志以及正确管理锁定文件。它弥合了传统 Node.js 开发与 Deno 的 Web 标准 API 之间的差距，使其成为高性能、安全后端和 CLI 开发的必备工具。

下载入口:https://github.com/openclaw/skills/tree/main/skills/ivangdavila/deno

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

Deno 应用场景

• 为生产环境的 Deno 服务实施细粒度的安全权限。
• 在保持完整的 npm 兼容性的情况下，将现有的 Node.js 项目迁移到 Deno。
• 管理远程依赖项并将其本地化（vendorize）以确保离线稳定性。
• 创建用于跨平台分发的自包含可执行二进制文件。
• 使用原生的 Deno 测试套件编写无泄漏的异步测试。

1. 该技能通过寻找 deno.json 或特定的 TypeScript 导入模式来检测 Deno 项目结构。
2. 它审计请求的操作以确定所需的特定权限，例如 --allow-net 或 --allow-read。
3. 代理配置导入映射和依赖项说明符，以正确解析模块路径。
4. 它生成符合 Deno 标准的 TypeScript 代码，遵循严格的扩展要求和 Web 标准 API。
5. 它通过管理 Deno 缓存和生成完整性锁定文件来为部署准备环境。

Deno 配置指南

要使用此技能，请确保您的本地计算机上已安装 Deno CLI。Openclaw Skills 需要 Deno 二进制文件来执行任务。

# 在 macOS 或 Linux 上安装 Deno
curl -fsSL https://deno.land/x/install/install.sh | sh

# 在 Windows 上安装 Deno
irm https://deno.land/install.ps1 | iex

通过在终端中运行 deno --version 来验证安装。

Deno 数据架构与分类体系

name: Deno
slug: deno
version: 1.0.0
description: "Build with Deno runtime avoiding permission gotchas, URL import traps, and Node.js migration pitfalls."
metadata: {"clawdbot":{"emoji":"??","requires":{"bins":["deno"]},"os":["linux","darwin","win32"]}}

When to Use

User needs Deno expertise — secure TypeScript runtime with permissions model. Agent handles permission configuration, dependency management via URLs/npm, and migration from Node.js.

Quick Reference

Permission Traps

• --allow-all in development — then production crashes because you don't know what permissions you actually need
• --allow-read without path — grants access to entire filesystem, security hole
• --allow-run without list — subprocess can run anything, specify: --allow-run=git,npm
• --allow-env without list — leaks all env vars, specify: --allow-env=API_KEY,DATABASE_URL
• --allow-net without list — can connect anywhere, specify hosts: --allow-net=api.example.com
• Missing permission in CI — hangs waiting for prompt that never comes, add --no-prompt

Import Traps

• Remote URLs in production — network failure = app won't start, vendor dependencies locally
• No lockfile by default — deps can change between runs, always use deno.lock
• @^1.0.0 semver syntax doesn't exist — use exact URLs or import maps
• Import maps in wrong place — must be in deno.json, not separate file (Deno 2.x)
• HTTPS required — HTTP imports blocked by default, most CDNs work but self-hosted may not
• URL typo — no error until runtime when import fails

TypeScript Traps

• .ts extension required in imports — model generates extensionless imports that fail
• tsconfig.json paths ignored — Deno uses import maps in deno.json, not tsconfig
• Type-only imports — must use import type or bundler may fail
• Decorators — experimental, different from tsc behavior
• /// — handled differently than tsc, may be ignored

Deployment Traps

• deno compile includes runtime — binary is 50MB+ minimum
• --cached-only requires prior cache — fresh server needs deno cache first
• Deno Deploy limitations — no filesystem, no subprocess, no FFI
• Environment variables — different API: Deno.env.get("VAR") not process.env.VAR
• Signals — Deno.addSignalListener not process.on("SIGTERM")

Testing Traps

• Deno.test different from Jest — no describe, different assertions
• Async test without await — test passes before promise resolves
• Resource leaks — tests fail if you don't close files/connections
• Permissions in tests — test may need different permissions than main code
• Snapshot testing — format differs from Jest snapshots

npm Compatibility Traps

• npm: specifier — works for most packages but native addons fail
• node: specifier required — import fs from 'fs' fails, need import fs from 'node:fs'
• node_modules optional — enable with "nodeModulesDir": true in deno.json
• package.json scripts — not automatically supported, use deno.json tasks
• Peer dependencies — handled differently, may get wrong versions

Runtime Differences

• Deno.readTextFile vs fs.readFile — different API, different error types
• fetch is global — no import needed, unlike Node 18-
• Top-level await — works everywhere, no wrapper needed
• Permissions at runtime — can request dynamically but user must approve