Deno

Un runtime JavaScript et TypeScript avec gestionnaire de paquets, formateur, linter, test runner, vérificateur de types et bundler dans un seul binaire. Exécute TypeScript directement.

Nécessite Deno 2.9+. Vérifiez avec deno --version, mettez à jour avec deno upgrade.

Deno fonctionne comme npm et bun

Deno n'est pas un écosystème séparé dans lequel porter du code :

• deno install lit un package.json existant et écrit un vrai node_modules.
• deno add express installe depuis npm. Les noms sans préfixe ciblent npm par défaut.
• deno task build exécute scripts.build depuis package.json ou tasks.build depuis deno.json. Si les deux le définissent, deno.json gagne.
• Les built-ins Node fonctionnent avec ou sans préfixe : node:fs et fs se résolvent tous deux.
• deno main.js exécute un fichier. deno run est optionnel.
• Deno lit tsconfig.json.

Ne demandez pas aux utilisateurs de réécrire les imports, d'adopter JSR, ou de restructurer comme condition préalable. Les deux vraies différences sont les permissions et les scripts de cycle de vie npm qui ne s'exécutent pas par défaut.

Les scripts d'une seule ligne n'ont besoin ni d'étape de build ni de tsconfig.json. Les applications et les projets framework conservent leur configuration normale.

Pour convertir un projet existant, consultez le skill migrate-to-deno.

Gestion des dépendances

deno install                  # install everything declared
deno add express              # from npm (unprefixed = npm)
deno add jsr:@std/path        # from JSR
deno add -D vitest            # dev dependency (package.json only)
deno remove express
deno outdated                 # list outdated deps
deno update                   # alias for `deno outdated --update`
deno update --latest          # ignore existing semver ranges
deno list                     # declared deps + resolved versions (npm ls)
deno why express              # why a package is in the tree
deno audit                    # vulnerability audit
deno ci                       # clean reproducible install for CI
dx cowsay hello               # run a package binary without installing (npx)

deno ci est la commande CI, pas deno install : elle demande deno.lock, supprime node_modules, installe strictement depuis le lockfile, et échoue si le lockfile est obsolète. --prod saute les devDependencies.

dx est npx / bunx / pnpm dlx, et un alias pour deno x. Il s'exécute avec le sandbox désactivé, traitez-le avec la même prudence que npx.

Deno n'installera pas une version publiée moins d'un jour plus tôt, limitant la fenêtre pour une version compromise. Contourner avec --min-dep-age, qui accepte les minutes (120), une durée ISO-8601 (P7D), une date limite, ou 0 pour désactiver :

deno add --min-dep-age=0 npm:some-package

Les scripts de cycle de vie (postinstall) ne s'exécutent pas par défaut — une surprise courante quand un addon natif semble cassé après installation. Approuvez une fois par projet :

deno approve-scripts                              # interactive picker
deno install --allow-scripts=npm:better-sqlite3

Où va la configuration

Mettez les dépendances dans package.json — tous les autres outils le lisent, et Deno le résout nativement. Utilisez deno.json pour les dépendances seulement s'il n'y a pas de package.json : un script standalone, ou un package JSR. Préférez tsconfig.json à compilerOptions dans deno.json, pour que tsc et les éditeurs voient les mêmes paramètres.

Committez deno.lock. Deno le peuple à partir d'un package-lock.json, yarn.lock, bun.lock, ou pnpm lockfile existant, en conservant les versions.

Layout de node_modules

Deno utilise le layout isolé de pnpm : vrais fichiers dans node_modules/.deno/, exposés par symlinks, pour qu'un package ne puisse importer que ce qu'il a déclaré. Pour un outil qui a besoin du flat hoisted tree de npm :

{ "nodeModulesLinker": "hoisted" }

nodeModulesDir s'applique seulement aux projets sans package.json, c'est donc rarement le bon paramètre.

Permissions

Deno n'accorde aucun accès au système de fichiers, réseau, environnement, ou subprocess à moins qu'on le lui demande.

deno run --allow-net=api.example.com --allow-read=./data main.ts
deno run -A main.ts          # allow everything

-S est --allow-sys, pas --allow-run. Chaque flag accepte une allowlist — --allow-net=example.com:443 bat un bare --allow-net. Les flags --deny-* correspondants gagnent toujours.

Sur Requires net access to "...", ajoutez cette permission spécifique. -A convient pour du code first-party fiable et lors d'une migration, mais c'est un mauvais défaut à committer dans une task.

Configuration

deno.json (ou .jsonc) est auto-découvert depuis le répertoire courant vers le haut.

{
  "tasks": {
    "dev": "deno watch -A main.ts",
    "start": "deno run -A main.ts"
  },
  "fmt": { "exclude": ["build/"] },
  "lint": { "rules": { "exclude": ["no-explicit-any"] } },
  "exclude": ["build/", "dist/"]
}

L'exclusion de niveau top exclude s'applique à chaque subcommand ; l'exclusion par outil la restreint.

deno.json accepte aussi imports, une import map pointant les bare specifiers sur des vrais. C'est comment un projet sans package.json déclare les dépendances, et comment un package JSR déclare les siennes aux côtés de name, version, exports.

Workspaces

Les workspaces npm, Yarn, et Bun fonctionnent d'emblée — Deno lit directement "workspaces" depuis package.json. pnpm est l'exception : pnpm-workspace.yaml est migré dans deno.json au premier lancement, qui doit alors être relancé.

{ "workspace": ["./packages/core", "./packages/cli"] }

Les membres sont explicites ou des globs d'un seul niveau ("packages/*"); ** et la négation ne sont pas supportés. Exécutez une task sur les membres avec deno task --filter '*' build.

Paquets : npm et JSR

Préférez npm — c'est là que l'écosystème est, et deno add express est le cas normal. Recourez à JSR pour la stdlib (@std/*), ou pour publier du TypeScript dont les consommateurs obtiennent les types sans étape de build. Mélanger c'est okay.

deno add jsr:@std/path npm:express
deno doc jsr:@std/path        # read a package's API from the terminal

Deno utilisait autrefois des imports d'URL complètes (https://deno.land/x/...). Elles fonctionnent toujours mais ne sont pas recommandées ; pour moderniser, deno add le paquet et importez le bare specifier.

Outillage intégré

deno fmt              # format (--check for CI)
deno lint             # lint (--fix, --rules)
deno test             # tests (--watch, --parallel, --coverage=dir)
deno check main.ts    # type-check without running
deno bench            # benchmarks
deno coverage         # coverage report from --coverage output
deno compile main.ts  # single-file executable (--target cross-compiles)
deno doc mod.ts       # docs (--html for a site)
deno info main.ts     # module graph and cache info

Ceux-ci couvrent prettier, eslint, jest/vitest, tsc, et pkg/nexe sans config ou dépendances — mais ce ne sont pas des remplaçants drop-in. La parité est incomplète, donc déplacer un projet établi c'est du vrai travail. Il n'y a pas besoin de migrer : gardez prettier, eslint, et vitest, et utilisez Deno comme runtime et gestionnaire de paquets. Préférez les outils intégrés pour les nouveaux projets.

Supprimez avec // deno-lint-ignore <rule>, // deno-lint-ignore-file, // deno-fmt-ignore, // deno-fmt-ignore-file. En Markdown, <!-- deno-fmt-ignore --> avant un bloc de code protège les snippets illustratifs qui ne sont pas du code standalone valide.

Exécuter du code

deno main.ts                 # deno run is optional
deno watch main.ts           # reload on change (replaces nodemon)
deno task dev                # task from package.json or deno.json
deno repl
deno eval "console.log(1)"

deno watch remplace les modules à chaud, redémarrant si cela échoue ; c'est un alias pour deno run --watch-hmr.

Un serveur HTTP n'a besoin d'aucune dépendance :

Deno.serve((_req) => new Response("Hello"));

Démarrer un nouveau projet

Scaffoldez plutôt que d'écrire les fichiers à la main :

deno init my-project          # script + test + deno.json
deno init --empty my-project  # just main.ts and deno.json
deno init --lib my-lib        # library laid out for JSR
deno create vite my-app       # scaffold from a package initializer

deno create est npm create / yarn create et couvre cet écosystème (deno create astro, etc). Les noms sans préfixe sont npm ; --jsr sélectionne JSR.

Publier

Pour npm le flux régulier fonctionne toujours — npm publish, ou deno pack pour construire le tarball d'abord. deno publish cible JSR seulement, à partir d'un deno.json avec name, version, et exports :

deno publish --dry-run
deno publish

L'attestation de provenance est automatique sur GitHub Actions. deno bump-version patch augmente la version, sur chaque membre à une racine workspace.

Guide : https://docs.deno.com/runtime/reference/cli/publish/

Revoir du code Deno

• -A committé dans une task où une subvention scopée marcherait.
• deno.lock non commité, ou CI exécutant deno install au lieu de deno ci.
• Spécifieurs inline jsr:/npm: dans un projet avec un package.json — utilisez deno add pour que la version vive à un seul endroit. Okay dans les scripts standalone.
• Un spécifieur sans contrainte de version.
• Dépendances ou options du compilateur dans deno.json quand package.json ou tsconfig.json existe.
• Manquant deno fmt --check, deno lint, deno check dans CI.

Lectures complémentaires

• https://docs.deno.com — documentation du runtime
• https://docs.deno.com/api/ — référence API Deno.*
• references/CLI.md — référence plus complète des subcommands et flags
• deno <subcommand> --help — faisant autorité et précis en version ; vérifiez-le avant de deviner un flag.