Deno 2.6 Lance dx : Le Nouveau npx Qui Promet de Révolutionner Comment Nous Exécutons les Packages

Salut HaWkers, Deno vient de lancer la version 2.6 avec une nouveauté qui va faciliter la vie de beaucoup de développeurs : la commande dx. Si vous avez déjà utilisé npx de Node.js, vous comprendrez immédiatement le propos, mais avec quelques différences importantes.

Saviez-vous qu'exécuter des packages directement depuis npm ou JSR peut être beaucoup plus sûr et efficace ? Le dx de Deno apporte cette expérience avec les garanties de sécurité pour lesquelles le runtime est connu.

Qu'est-ce que Deno dx

Le dx est la réponse de Deno au npx. Il permet d'exécuter des binaires de packages npm et JSR sans avoir besoin de les installer globalement. Mais il va plus loin : il hérite de tout le modèle de sécurité de Deno.

Comparaison Rapide

npx (Node.js) :

Télécharge et exécute des packages
Accès total au système
Pas de restrictions de sécurité

dx (Deno) :

Télécharge et exécute des packages
Permissions granulaires
Sécurité par défaut

# Avec npx (Node.js)
npx create-react-app mon-app

# Avec dx (Deno)
deno dx create-react-app mon-app

La syntaxe est familière, mais le comportement sous le capot est différent.

Comment Utiliser dx en Pratique

La commande dx fonctionne tant avec les packages npm qu'avec les packages JSR (le registry propre de Deno).

Exécuter des Packages npm

# Exécuter un package npm directement
deno dx npm:eslint --init

# Exécuter une version spécifique
deno dx npm:typescript@5.3.0 --version

# Exécuter avec alias
deno dx npm:prettier --check .

Exécuter des Packages JSR

# Exécuter un package du JSR
deno dx jsr:@std/cli/parse-args

# Exécuter un outil de test
deno dx jsr:@std/testing/snapshot

Exemples Pratiques du Quotidien

# Démarrer un nouveau projet Vite
deno dx npm:create-vite@latest mon-projet

# Lancer json-server pour mock d'API
deno dx npm:json-server db.json

# Formater le code avec Biome
deno dx npm:@biomejs/biome format .

# Générer la documentation avec TypeDoc
deno dx npm:typedoc --entryPoints src/index.ts

Différentiels de Sécurité

Le grand avantage de dx sur npx est dans le modèle de sécurité. Deno ne fait confiance à aucun code par défaut.

Permissions Granulaires

Quand vous exécutez un package avec dx, Deno applique les mêmes restrictions que pour n'importe quel autre code :

# Exécuter avec permission réseau uniquement
deno dx --allow-net npm:http-server

# Exécuter avec permission de lecture dans un répertoire spécifique
deno dx --allow-read=./src npm:eslint ./src

# Exécuter avec permissions minimales
deno dx --allow-read --allow-write npm:prettier --write .

Comparatif de Sécurité

Aspect	npx	dx
Accès au filesystem	Total	Nécessite permission
Accès au réseau	Total	Nécessite permission
Variables d'environnement	Total	Nécessite permission
Sous-processus	Total	Nécessite permission
FFI	Autorisé	Nécessite permission

Scénario de Risque avec npx

Imaginez que vous exécutez un package malveillant :

# Avec npx - le package a accès total
npx package-suspect
# Peut lire les clés SSH, les envoyer à un serveur distant...

# Avec dx - sans permissions, rien ne se passe
deno dx npm:package-suspect
# Erreur : accès refusé

Autres Nouveautés de Deno 2.6

Le lancement 2.6 a apporté plus que le dx. Voyez d'autres améliorations significatives :

deno audit

Maintenant vous pouvez auditer les vulnérabilités dans les dépendances :

# Vérifier les vulnérabilités connues
deno audit

# Sortie exemple :
# Found 2 vulnerabilities:
# - lodash@4.17.20: CVE-2021-23337 (high)
# - axios@0.21.0: CVE-2021-3749 (medium)

Permissions Plus Granulaires

Deno 2.6 a introduit des permissions encore plus fines :

# Autoriser uniquement la lecture de fichiers .json
deno run --allow-read="*.json" script.ts

# Autoriser le réseau uniquement pour un domaine spécifique
deno run --allow-net="api.exemple.com" script.ts

Améliorations TypeScript

L'intégration avec tsgo (TypeScript en Go) a apporté :

Gains de performance :

Vérification de types 30% plus rapide
Utilisation mémoire réduite
Hot reload plus réactif

Stack Traces Améliorées

Maintenant les erreurs sont plus lisibles :

# Avant (Deno 2.5)
Error: Something went wrong
    at Object.runMicrotasks (ext:core/01_core.js:456:11)
    at processTicksAndRejections (ext:deno_node/_next_tick.ts:65:10)
    at async Module._compile (ext:deno_node/module.ts:512:9)
    ...

# Après (Deno 2.6)
Error: Something went wrong
    at fetchData (src/api.ts:15:5)
    at main (src/index.ts:8:3)

dx vs npx vs bunx

Avec trois options sur le marché, laquelle choisir ?

Comparatif Complet

Caractéristique	npx	dx	bunx
Vitesse	Modérée	Élevée	Très Élevée
Sécurité	Basse	Élevée	Basse
Compatibilité npm	Totale	Élevée	Élevée
Cache intelligent	Oui	Oui	Oui
Permissions	Non	Oui	Non

Quand Utiliser Chacun

Utilisez npx quand :

Vous avez besoin de compatibilité totale avec l'écosystème Node
Vous êtes dans un projet legacy qui dépend de Node
Des outils spécifiques qui ne fonctionnent pas dans Deno

Utilisez dx quand :

La sécurité est prioritaire
Vous voulez de la consistance avec les projets Deno
Vous avez besoin de permissions granulaires

Utilisez bunx quand :

La vitesse est la priorité absolue
Des projets qui utilisent déjà Bun
Vous n'avez pas de restrictions de sécurité

Intégration avec les Workflows Existants

Le dx s'intègre bien avec les outils que vous utilisez déjà.

Scripts dans deno.json

{
  "tasks": {
    "lint": "deno dx npm:eslint src/",
    "format": "deno dx npm:prettier --write .",
    "test:e2e": "deno dx npm:playwright test",
    "docs": "deno dx npm:typedoc --out docs src/"
  }
}

CI/CD avec GitHub Actions

name: CI
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v1
        with:
          deno-version: v2.x
      - run: deno dx npm:eslint . --max-warnings 0
      - run: deno dx npm:prettier --check .

Docker

FROM denoland/deno:2.6.0

WORKDIR /app
COPY . .

# Utiliser dx pour les outils de build
RUN deno dx npm:esbuild --bundle src/index.ts --outfile=dist/bundle.js

CMD ["deno", "run", "--allow-net", "dist/bundle.js"]

Migrer de npx vers dx

Si vous voulez migrer vos scripts de npx vers dx, le processus est simple :

Pas à Pas

1. Identifiez les commandes npx dans le projet :

# Chercher dans package.json et scripts
grep -r "npx " .

2. Remplacez npx par deno dx npm:

# Avant
npx eslint .

# Après
deno dx npm:eslint .

3. Ajoutez les permissions nécessaires :

# Si la commande a besoin de lire des fichiers
deno dx --allow-read npm:eslint .

# Si elle a besoin du réseau
deno dx --allow-net npm:create-react-app my-app

Table de Conversion Commune

Commande npx	Commande dx
`npx eslint .`	`deno dx --allow-read npm:eslint .`
`npx prettier --write .`	`deno dx --allow-read --allow-write npm:prettier --write .`
`npx http-server`	`deno dx --allow-net --allow-read npm:http-server`
`npx create-vite`	`deno dx --allow-read --allow-write --allow-net npm:create-vite`

Conclusion

Le dx de Deno 2.6 représente une évolution naturelle dans la façon dont nous exécutons des packages JavaScript. En gardant la familiarité de npx mais en ajoutant des couches de sécurité, Deno offre une alternative mature pour les développeurs qui se soucient de l'intégrité de leurs systèmes.

Si vous utilisez déjà Deno, le dx est un ajout naturel à votre workflow. Si vous êtes encore dans l'écosystème Node, ça vaut la peine d'expérimenter dx dans de nouveaux projets pour sentir les bénéfices du modèle de sécurité de Deno.

Si vous voulez comprendre plus les différences entre les runtimes JavaScript modernes, je recommande de consulter l'article Anthropic Achète Bun où nous discutons des changements récents sur le marché des runtimes.