From deno-skills
Guides Deno project initialization, package management prioritizing JSR then npm, deno.json configuration, CLI commands like fmt/lint/test, import maps, and permissions.
npx claudepluginhub denoland/skills --plugin deno-skillsThis skill uses the workspace's default tool permissions.
This skill provides foundational knowledge for building modern Deno applications. Deno is a secure JavaScript/TypeScript runtime that runs TypeScript directly, has built-in tools (formatter, linter, test runner), and uses modern package management through JSR.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
This skill provides foundational knowledge for building modern Deno applications. Deno is a secure JavaScript/TypeScript runtime that runs TypeScript directly, has built-in tools (formatter, linter, test runner), and uses modern package management through JSR.
deno.json settingsApply these practices whenever working in a Deno project (identified by the presence of deno.json).
This skill applies only to Deno-specific questions. Follow these rules:
jsr: imports, deno add, or deno.json configuration in responses about other technologies.When helping users migrate from deprecated patterns, describe the old approach generically and ONLY show the correct modern code. Never write out actual deprecated URLs or import paths, even in "before/after" comparisons. The string deno.land/x/ must never appear in your response, in any context.
jsr: approachOnly demonstrate the correct, current approach.
When adding dependencies, follow this priority order:
JSR packages (jsr:) - Preferred for Deno-native packages
jsr:@std/http, jsr:@fresh/corenpm packages (npm:) - Fully supported, use when no JSR alternative exists
npm:express, npm:zodAVOID: Old URL-based imports - Deprecated registry
jsr: insteadThe Deno standard library lives at @std/ on JSR:
// deno.json
{
"imports": {
"@std/assert": "jsr:@std/assert@1",
"@std/http": "jsr:@std/http@1",
"@std/path": "jsr:@std/path@1"
}
}
import { serve } from "@std/http";
import { join } from "@std/path";
import { assertEquals } from "@std/assert";
Always use jsr:@std/* for the standard library (the old URL-based imports are deprecated).
Reference: https://docs.deno.com/runtime/fundamentals/
Key concepts:
--allow-net, --allow-read, --allow-envimports fieldRun these commands regularly, especially after significant changes:
deno fmt # Format all files
deno lint # Check for issues
deno test # Run tests
deno add jsr:@std/http # Add a package
deno install # Install all dependencies
deno update # Update all dependencies to latest compatible versions
deno update jsr:@std/http # Update a specific dependency
deno update vs deno upgrade:
deno update - Updates project dependencies in deno.json (and package.json) to their latest compatible versions. Respects semver ranges. Use this to keep your dependencies current.deno upgrade - Updates the Deno runtime itself to the latest version. Has nothing to do with project dependencies.After running deno update, always check for breaking API changes - especially for alpha/pre-release packages where semver ranges can pull in breaking updates.
In CI pipelines, use --check with deno fmt so it fails without modifying files:
deno fmt --check # Fail if not formatted
deno lint # Check for issues
deno test # Run tests
In deno.json, you can exclude directories from formatting/linting:
{
"fmt": {
"exclude": ["build/"]
},
"lint": {
"exclude": ["build/"]
}
}
A folder can also be excluded from everything at the top level:
{
"exclude": ["build/"]
}
For deploying to Deno Deploy, see the dedicated deno-deploy skill.
Quick command: deno deploy --prod
When more information is needed:
deno doc <package> - Generate docs for any JSR or npm package locally| Command | Purpose |
|---|---|
deno run file.ts | Run a TypeScript/JavaScript file |
deno task <name> | Run a task from deno.json |
deno fmt | Format code |
deno lint | Lint code |
deno test | Run tests |
deno add <pkg> | Add a package |
deno install | Install dependencies |
deno update | Update project dependencies |
deno upgrade | Update Deno runtime itself |
deno doc <pkg> | View package documentation |
deno deploy --prod | Deploy to Deno Deploy |
Using old URL-based imports instead of JSR
The old URL-based imports are deprecated. Always use jsr: imports with bare specifiers instead.
// ✅ Correct - use JSR and a bare specifier
import { serve } from "@std/http";
import { join } from "@std/path";
// deno.json
{
"imports": {
"@std/http": "jsr:@std/http@1",
"@std/path": "jsr:@std/path@1"
}
}
Inline specifiers are fine in single file scripts, but if a deno.json exists then it should go there. It's preferable to place npm dependencies in a package.json if a package.json exists.
Forgetting to run fmt/lint before committing
Always format and lint before committing:
# ✅ Always format and lint first
deno fmt && deno lint && git add . && git commit -m "changes"
Running code without permission flags
# ✅ Grant specific permissions
deno run --allow-net server.ts
Without permission flags, Deno will show "Requires net access" errors. Always grant the specific permissions your code needs.
Not using deno add for dependencies
# ✅ Use deno add to manage dependencies
deno add jsr:@std/http
Using deno add ensures your lockfile stays in sync. Manually editing imports without updating deno.json works but misses lockfile benefits.