Présentation

Le projet Deslop propose un ensemble de règles pour Oxlint destiné à détecter les patterns de code générés par l’intelligence artificielle dans des projets TypeScript. Le dépôt GitHub compte 32 commits, 9 étoiles et aucune description officielle, ce qui indique une communauté très restreinte mais active autour de ce plugin.

Installation et intégration

Deslop se distribue via npm sous le nom ai-deslop. L’installation s’effectue avec la commande suivante :

npm install --save-dev ai-deslop

Le plugin @oxlint/plugins est déclaré comme dépendance d’exécution et doit être maintenu en phase avec la version d’Oxlint utilisée. Le fichier de configuration typique, compatible avec les runtimes Bun, Deno ou Node.js, ressemble à :

import { defineConfig } from "oxlint";
import { configs as deslopConfigs } from "ai-deslop";
export default defineConfig({
  jsPlugins: ["ai-deslop"],
  options: deslopConfigs.recommended.options,
  rules: deslopConfigs.recommended.rules
});

Cette intégration montre que Deslop ne fournit pas de moteur d’analyse propre, mais s’appuie entièrement sur le parseur et l’infrastructure d’Oxlint.

Catalogue de règles

Les règles sont regroupées en plusieurs thématiques :

Type safety and evidence : neuf règles, dont no-chained-type-assertions qui bloque les assertions imbriquées en angle‑brackets, et require-safety-comment-for-type-assertion qui impose un commentaire invariant pour chaque assertion non‑constante. Ces règles visent à empêcher les développeurs d’ajouter des preuves de type sans justification, un problème fréquent dans le code produit par les modèles de génération.

Code quality and APIs : cinq règles, parmi lesquelles no-array-filter-map qui refuse les passes consécutives filter/map et encourage l’usage d’itérateurs paresseux, et no-reflect-apply qui interdit l’appel direct de Reflect.apply pour réduire la surface d’attaque.

Tests : quatre règles ciblant les pratiques de test, comme no-call-only-assertions qui signale les tests ne vérifiant que les appels de mock, et no-module-mocking qui rejette les mocks de modules dans Vitest ou Jest, afin de garantir que les tests restent représentatifs du comportement réel.

Opt‑in et standard : plusieurs règles optionnelles (ex. no-duplicate-consts) et des règles standard d’Oxlint déjà activées, telles que typescript/no-deprecated ou no-unreachable, qui renforcent la conformité aux bonnes pratiques TypeScript.

Analyse des impacts et limites

En filtrant les constructions de type « low‑evidence », Deslop réduit le risque d’introduire des incohérences de typage qui pourraient se traduire par des erreurs d’exécution non détectées à la compilation. La règle no-unknown-parameters, par exemple, empêche la propagation de paramètres de type unknown dans les signatures publiques, limitant ainsi les vecteurs d’injection de données non validées.

Le plugin ne propose pas de correcteurs automatiques pour la plupart des règles, ce qui oblige les développeurs à réviser manuellement le code signalé. De plus, la dépendance à la version d’Oxlint impose une synchronisation stricte ; un désalignement peut entraîner des erreurs de chargement du plugin. Enfin, le scope du projet reste limité à TypeScript ; les projets JavaScript purs ou les langages compilés vers TypeScript ne bénéficient pas de ces contrôles.

En résumé, Deslop fournit une couche supplémentaire de validation pour les projets TypeScript où l’IA est utilisée comme co‑développeur. Son efficacité dépend de la discipline des équipes à appliquer les commentaires de sécurité et à maintenir la compatibilité avec Oxlint.