DenoX CLI : Créez des projets et des fonctionnalités sans perdre le contrôle

L’un des objectifs principaux de DenoX est de réduire le travail de développement répétitif sans priver les ingénieurs de leur contrôle. Le framework fournit sa propre CLI sous forme d’un seul fichier TypeScript capable de créer des projets, de générer des fonctionnalités complètes, de supprimer des modules en toute sécurité et de mettre à jour le framework lui-même.

Contrairement à de nombreuses CLIs modernes qui intègrent des dizaines de paquets, la CLI de DenoX s’appuie entièrement sur les capacités natives de Deno.

Installation

Installez-le avec une seule commande :

deno install -grA -n denox https://raw.githubusercontent.com/olavomello/denox/main/cli/main.ts

Ou exécutez-la sans installation :

deno run -A https://raw.githubusercontent.com/olavomello/denox/main/cli/main.ts new my-shop

La CLI est un fichier autonome : aucune dépendance externe et aucun import depuis le framework lui-même.

Création d’un projet

La création d’une nouvelle application se fait en une seule commande :

denox new my-shop

Le squelette de projet va au-delà du simple dépôt d’un modèle sur le disque. Il télécharge le starter officiel, supprime son historique Git, crée un répertoire propre, réinitialise le champ de version à 0.1.0, vide le journal des modifications, réécrit le fichier README avec le nouveau nom, et met à jour denox.config.ts en conséquence.

Le résultat est prêt à être développé et respecte déjà les vérifications du script deno task ci sans nécessiter de nettoyage manuel.

Les modèles personnalisés fonctionnent également :

denox new my-app --template=<repository>

Génération d’une fonctionnalité complète

La plus grande force de l’interface en ligne de commande réside dans sa capacité à générer toute une fonctionnalité MVC à partir d’une seule commande.

denox g feature reviews

Au lieu de placeholders vides, la génération produit une partie d’API complète au format MVC : modèle et DTO, interface de repository ainsi que des implémentations en mémoire et avec Deno KV, service, contrôleur, routes, une description OpenAPI située à côté du code, et un test d’intégration de base.

L’enregistrement dans src/api/main.ts s’effectue automatiquement, ce qui permet d’accéder à cette fonctionnalité sans configuration manuelle.

OpenAPI intégré

Chaque fonctionnalité générée dispose de sa propre description OpenAPI.

Conséquences :

• La documentation est située à côté de l’implémentation
• Les tests de parité des routes continuent de fonctionner correctement
• Lancement :

deno task insomnia

génère automatiquement la collection Insomnia.

Il n’y a pas de tâche supplémentaire de maintenance des documents API à effectuer manuellement.

Génération de code sécurisée

La CLI reste prudente lorsqu’elle modifie du code existant.

Lorsque le marqueur // denox:features est manquant ou modifié, l’outil refuse d’inventer un point d’insertion.

Il écrit néanmoins les nouveaux fichiers de fonctionnalités, affiche les lignes précises à coller manuellement, et laisse intacts tous les fichiers sources existants.

Des noms incorrects ou des IDs de fonctionnalités dupliqués empêchent l’exécution de la commande avant que l’arborescence ne change.

Suppression d’une fonctionnalité

L’opération inverse est tout aussi importante que la génération.

denox rm feature reviews

La suppression a pour but d’éviter des projets endommagés.

La ligne de commande supprime d’abord toutes les références au routeur concernant cette fonctionnalité.

Ce n’est qu’après avoir complètement déconnecté l’application que les fichiers sont supprimés.

Même si le processus s’arrête en cours de route, le projet ne contient jamais d’importations pointant vers des fichiers manquants.

Lorsque la suppression est terminée, src/api/main.ts reprend son état antérieur à la génération : aucune importation orpheline et pas de lignes vides superflues.

Aperçu préliminaire avec :

denox rm feature reviews --dry-run

Les modules de base restent verrouillés. Les tentatives de suppression des fonctionnalités intégrées — telles que l’authentification, les utilisateurs, les produits, les paiements, la santé et les contacts — sont rejetées.

Mise à jour du framework

Mettez vos projets à jour avec :

denox upgrade

Les mises à jour ne suppriment pas l’ensemble de la structure. Seules les chemins appartenant au framework changent.

Ces chemins sont listés explicitement dans .denox-core.json.

Tout ce qui se trouve en dehors de ce fichier reste inchangé, y compris :

• Les fonctionnalités générées
• La configuration du projet
• Les fichiers d’environnement
• Le code spécifique à l’application

Modes de mise à jour supplémentaires :

denox upgrade --dry-run
denox upgrade --interactive
denox upgrade --ref=v1.2.0

Au préalable de la mise à jour, l’interface en ligne de commande vérifie que l’arbre de travail Git est propre. Les modifications non commitées interrompent l’opération sauf si forcé, ce qui réduit les pertes de données accidentelles.

Génération des pages

La CLI prend également en charge le routage basé sur les fichiers du framework.

denox g page docs/faq

ou

denox g page items/[id]

Une fois la page créée, le tableau de routage est régénéré automatiquement.

Filosophie derrière la CLI DenoX

La CLI reflète le framework : privilégier les conventions aux paramètres de configuration sans pour autant céder le contrôle.

Ces principes se traduisent par des règles concrètes : les fichiers existants restent inchangés, les sources modifiées manuellement ne sont pas réécrites, les commandes destructrices proposent l’option --dry-run, les modules appartenant au framework ne peuvent pas être supprimés à la légère, OpenAPI reste associé aux routes, et les fichiers du framework restent distincts du code de l’application.

Tout cela permet d’obtenir une CLI petite et prévisible : moins de code générique, sans dissimuler ce qui a changé.