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
| Topic | File |
|---|
| Permission system | INLINECODE0 |
| Imports and dependencies |
imports.md |
| Node.js migration |
node-compat.md |
Permission Traps
- -
--allow-all in development — then production crashes because you don't know what permissions you actually need - INLINECODE4 without path — grants access to entire filesystem, security hole
- INLINECODE5 without list — subprocess can run anything, specify: INLINECODE6
- INLINECODE7 without list — leaks all env vars, specify: INLINECODE8
- INLINECODE9 without list — can connect anywhere, specify hosts: INLINECODE10
- Missing permission in CI — hangs waiting for prompt that never comes, add INLINECODE11
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 INLINECODE12
- INLINECODE13 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 - INLINECODE16 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
- INLINECODE19 — handled differently than tsc, may be ignored
Deployment Traps
- -
deno compile includes runtime — binary is 50MB+ minimum - INLINECODE21 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 INLINECODE24 - Signals —
Deno.addSignalListener not INLINECODE26
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 - INLINECODE30 specifier required —
import fs from 'fs' fails, need INLINECODE32 - INLINECODE33 optional — enable with
"nodeModulesDir": true in deno.json - INLINECODE35 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 - INLINECODE38 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
使用场景
用户需要Deno专业知识——具备权限模型的安全TypeScript运行时。代理需处理权限配置、通过URL/npm的依赖管理,以及从Node.js的迁移。
快速参考
| 主题 | 文件 |
|---|
| 权限系统 | permissions.md |
| 导入与依赖 |
imports.md |
| Node.js迁移 | node-compat.md |
权限陷阱
- - 开发时使用--allow-all——但生产环境崩溃,因为你不知道实际需要哪些权限
- --allow-read未指定路径——授予整个文件系统访问权限,存在安全漏洞
- --allow-run未指定列表——子进程可运行任何程序,需指定:--allow-run=git,npm
- --allow-env未指定列表——泄露所有环境变量,需指定:--allow-env=APIKEY,DATABASEURL
- --allow-net未指定列表——可连接任意地址,需指定主机:--allow-net=api.example.com
- CI中缺少权限——挂起等待永远不会出现的提示,需添加--no-prompt
导入陷阱
- - 生产环境使用远程URL——网络故障导致应用无法启动,应将依赖本地化
- 默认无锁文件——依赖可能在不同运行间变化,始终使用deno.lock
- @^1.0.0语义化版本语法不存在——使用精确URL或导入映射
- 导入映射位置错误——必须放在deno.json中,而非单独文件(Deno 2.x)
- 必须使用HTTPS——默认阻止HTTP导入,大多数CDN可用但自托管可能不行
- URL拼写错误——直到运行时导入失败才会报错
TypeScript陷阱
- - 导入中需要.ts扩展名——模型生成无扩展名的导入会失败
- tsconfig.json路径被忽略——Deno使用deno.json中的导入映射,而非tsconfig
- 仅类型导入——必须使用import type,否则打包器可能失败
- 装饰器——实验性功能,与tsc行为不同
- /// ——处理方式与tsc不同,可能被忽略
部署陷阱
- - deno compile包含运行时——二进制文件至少50MB+
- --cached-only需要预先缓存——新服务器需先执行deno cache
- Deno Deploy限制——无文件系统、无子进程、无FFI
- 环境变量——不同API:使用Deno.env.get(VAR)而非process.env.VAR
- 信号——使用Deno.addSignalListener而非process.on(SIGTERM)
测试陷阱
- - Deno.test与Jest不同——无describe,断言方式不同
- 异步测试未使用await——测试在Promise解决前就通过
- 资源泄漏——未关闭文件/连接会导致测试失败
- 测试中的权限——测试可能需要与主代码不同的权限
- 快照测试——格式与Jest快照不同
npm兼容性陷阱
- - npm:说明符——适用于大多数包,但原生插件会失败
- 需要node:说明符——import fs from fs会失败,需使用import fs from node:fs
- node_modules可选——在deno.json中启用nodeModulesDir: true
- package.json脚本——不自动支持,使用deno.json任务
- 对等依赖——处理方式不同,可能获取错误版本
运行时差异
- - Deno.readTextFile vs fs.readFile——不同API,不同错误类型
- fetch是全局的——无需导入,与Node 18-不同
- 顶层await——随处可用,无需包装器
- 运行时权限——可动态请求,但需用户批准