Skill: ivangdavila/deno (version 1.0.0)

--- 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 | Topic | File | |-------|------| | Permission system | `permissions.md` | | 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 - `--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 - `/// <reference>` — 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


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)