Les nouvelles fonctionnalités intégrées de Node.js qui remplacent les paquets npm populaires

• Ces derniers temps, Node.js évolue rapidement en intégrant directement dans le runtime des fonctionnalités auparavant possibles uniquement via des paquets npm
• Cela permet de réduire les risques de sécurité de la supply chain, d’améliorer la portabilité du code, de diminuer les dépendances et de simplifier la maintenance, tout en contribuant à de meilleures performances et à une plus grande stabilité en production
• Avec l’ajout d’API globales comme fetch(), WebSocket, node:test, il devient possible de développer sans paquets populaires comme node-fetch, ws ou mocha
• L’extension des fonctionnalités du système de fichiers fournit des options comme fs.glob(), fs.rm(), fs.mkdir() pour remplacer glob, rimraf, mkdirp
• Du côté des API utilitaires et cryptographiques, crypto.randomUUID(), util.styleText(), atob/btoa sont désormais inclus en standard, rendant inutiles des paquets comme uuid ou chalk
• Certaines fonctionnalités (node:sqlite, URLPattern, --env-file, exécution de TypeScript, etc.) restent encore au stade expérimental
• Le point important est que, grâce à cette évolution propre à Node.js, il devient possible de développer des applications modernes avec le seul runtime de base

---

Principaux paquets npm désormais remplacés par les fonctionnalités intégrées de Node.js

• Node.js s’est longtemps appuyé sur divers paquets npm pour les utilitaires HTTP, les helpers du système de fichiers, etc.
• Mais dans les versions récentes (v18 à v22), la tendance à intégrer directement ces fonctions dans le runtime s’est renforcée
• Cela réduit la complexité de gestion des paquets ainsi que l’exposition aux risques de sécurité

1. node-fetch → Global fetch()

• À partir de Node.js 18, le même fetch() que dans le navigateur est fourni comme fonction globale
• Les requêtes HTTP peuvent donc être gérées sans node-fetch
• Introduit à titre expérimental en v17.5.0, puis stabilisé en v18.0.0
• En revanche, sur les versions antérieures à 18, node-fetch reste nécessaire

2. ws → Global WebSocket

• Depuis Node.js 21, la classe globale WebSocket permet les connexions WebSocket côté client
  • Ajoutée à titre expérimental en v21.0.0, elle reste expérimentale à ce jour
• Pour une implémentation WebSocket côté serveur, il faut toujours utiliser le paquet ws ou des bibliothèques similaires

3. Frameworks de test → node:test

• Depuis Node.js 18, un runner de tests intégré node:test est fourni pour remplacer mocha, jest, etc.
  • Introduit à titre expérimental en v18.0.0, stabilisé en v20.0.0
  • Il prend en charge l’écriture et l’exécution de tests unitaires de base
• Si vous avez besoin de snapshots, de mocking, d’un riche écosystème de plugins, les frameworks tiers restent utiles
  • Suffisant pour des tests au niveau module, mais les frameworks existants gardent des avantages pour le développement d’applications full-stack

4. sqlite3 / better-sqlite3 → node:sqlite

• Node.js est en train d’introduire un module expérimental node:sqlite pour l’accès à SQLite
  • Cela résout les problèmes de compilation et les erreurs de mise à niveau liés aux paquets à liaisons natives existants
  • Les opérations de base sont prises en charge, comme la création de bases en mémoire ou de tables
• Comme cela reste expérimental, il est toujours recommandé d’utiliser des paquets communautaires si vous avez besoin de réglages avancés de performance ou de fonctionnalités supplémentaires

5. chalk / kleur → util.styleText()

• Depuis Node.js 20.12.0, util.styleText() permet de styliser le texte dans la console
  • Stabilisé en v22.17.0
  • Application de styles de texte de base comme les couleurs, le gras ou le soulignement
• Si vous avez besoin de thèmes complexes, d’une syntaxe chaînée ou de compatibilité descendante, vous pouvez continuer à utiliser chalk, etc.

6. strip-ansi → util.stripVTControlCharacters()

• La suppression des codes d’échappement ANSI est fournie par une fonction intégrée de Node.js
  • Permet de retirer proprement les caractères de contrôle dans les logs
• La plupart des usages sont couverts nativement, rendant inutile un paquet tiers

7. glob → fs.glob()

• Depuis Node.js 22, une fonction intégrée fs.glob() a été ajoutée pour la recherche par motifs de fichiers
  • Ajoutée en v22.0.0, stabilisée dans la v22.17.0 LTS
  • Recherche de fichiers avec des motifs glob comme **/*.js
• Si vous devez conserver la compatibilité avec d’anciennes versions de Node.js, le paquet glob reste pertinent

8. rimraf → fs.rm({ recursive: true })

• La suppression récursive de répertoires est prise en charge par une API native de Node.js
  • Implémentée via les options recursive et force de fs.rm()
  • Disponible depuis environ la v12.10.0 et stabilisée sur toutes les versions LTS actuelles
• Il est possible de supprimer des répertoires en toute sécurité sans le paquet rimraf

9. mkdirp → fs.mkdir({ recursive: true })

• La création récursive de répertoires est fournie via l’option recursive de fs.mkdir()
  • Ajoutée à partir de la v10.12.0 et stable depuis longtemps
• Il est possible de créer des répertoires imbriqués sans paquet distinct

10. uuid → crypto.randomUUID()

• Depuis Node.js 14.17.0, la fonction de génération d’UUID crypto.randomUUID() est disponible
  • Incluse comme fonctionnalité stable du module cryptographique
• Permet de générer des identifiants aléatoires sûrs sans le paquet uuid

11. base64-js / atob → atob, btoa

• Depuis Node.js 20, les fonctions globales atob et btoa sont fournies
  • Même API d’encodage/décodage Base64 que dans le navigateur
  • Offre une option supplémentaire à côté de Buffer
• Le traitement Base64 devient possible sans polyfill

12. url-pattern → URLPattern

• Depuis Node.js 20, l’API globale URLPattern est proposée à titre expérimental
  • Prend en charge le matching de routes, l’extraction de paramètres de chemin, etc.
  • Nécessite encore une stabilisation
• Le matching de motifs d’URL peut ainsi être géré via une API Web standard

13. dotenv → --env-file

• Depuis Node.js 20.10.0, le flag --env-file permet de charger des variables d’environnement
  • Charge directement un fichier .env à l’exécution
  • La fonctionnalité reste encore expérimentale
• Pour des fonctions avancées comme l’expansion de variables ou plusieurs fichiers env, le paquet dotenv reste nécessaire

14. event-target-shim → EventTarget

• Depuis Node.js 15.0.0, le système d’événements standard Web EventTarget est fourni globalement
  • Stabilisé en v15.4.0
  • Prend en charge le même modèle de gestion d’événements que dans le navigateur
• Peut être utilisé comme alternative à EventEmitter

15. tsc → exécution TypeScript dans Node.js

• Depuis Node.js 21, il est possible d’exécuter directement des fichiers .ts avec le flag --experimental-strip-types
  • Seule la suppression des types est effectuée, sans prise en charge du type checking complet
  • La fonctionnalité est encore expérimentale
• Pour les builds de production, la vérification statique des types, la génération de fichiers de déclaration et un type checking complet, tsc reste nécessaire

Conclusion

• L’évolution de Node.js vise à réduire la dépendance aux paquets externes et à renforcer la maturité de la plateforme elle-même
• Sur la version LTS récente (v22), de nombreux paquets npm sont déjà devenus inutiles,
  ce qui représente une nette amélioration en matière de sécurité, de performance et de maintenabilité
• Dans les environnements d’exploitation en entreprise, des solutions comme N|Solid sont utilisées pour suivre ces changements en temps réel
  • Analyse des performances en charge réelle des fonctionnalités intégrées (fetch, node:test, crypto.randomUUID(), etc.)
  • L’agent IA N|Sentinel fournit un suivi de l’usage et des recommandations d’optimisation au niveau du code

[nemorize]

Les API fournies par le runtime sont de plus en plus nombreuses.. En particulier pour les API réseau, les URL, le traitement des chaînes comme b64, etc...

C'est carrément... PH..

[carnoxen]

On dirait que UUID v7 est encore un peu prématuré.

[click]

Je pense qu’il faut considérer les pilotes de base de données sous un angle différent des fonctionnalités qui devraient relever d’autres bibliothèques standard. Pourquoi Bun, comme d’autres, cherche-t-il à intégrer un pilote SQLite directement dans le runtime ?
Est-ce parce que Python l’intègre en standard ?

À mon avis, plutôt que d’intégrer les fonctionnalités SQLite, il serait plus important de définir un standard d’interface pour les pilotes de base de données.
Comme l’interface diffère selon les pilotes, le vrai problème n’est-il pas qu’il est difficile de prendre en charge plusieurs types de bases de données sans utiliser d’ORM ?

[aer0700]

Je suppose qu’ils l’ont inclus parce que, pour de petits services comme un simple blog personnel, sqlite suffit souvent largement. C’est pratique de l’avoir.

[tujuc]

Je pense que sqlite a été inclus parce que son interface est la plus simple et qu’il constitue une bonne référence à consulter.

Et je ne vois pas vraiment pourquoi il faudrait créer le standard d’interface de driver de base de données dont vous parlez. J’ai l’impression d’avoir déjà vu quelque chose de similaire en PHP.

Pour les requêtes complexes que l’ORM ne peut pas gérer, on utilise encore des requêtes RAW...
Vous devez souvent utiliser des bases de données hétérogènes, on dirait... Pourquoi ne pas créer une bibliothèque ? :)

[click]

Il est assez courant que des runtimes comme Python, Java, C#, Go, etc. définissent une interface standard pour les drivers de base de données.
Mais avec Node, même entre drivers visant pourtant SQLite, l’exécution des statements diffère entre execute() et exec(), si bien que remplacer simplement un driver impose déjà quelques modifications.

Ce n’est pas fréquent, mais quand on change de base de données, c’est aussi assez contraignant.
Si on part de MySQL puis qu’on décide de passer à PostgreSQL, par exemple parce qu’on n’aime pas ce que fait Oracle ou parce qu’on a absolument besoin d’une extension PostgreSQL,
avec une interface standard comme JDBC, il suffit surtout de valider le SQL ; dans l’écosystème Node, l’effet de bord, c’est qu’il faut refaire toute la logique d’appel à la base de données.

+On m’a recommandé d’essayer de créer une bibliothèque, mais avoir une interface commune standard facilite vraiment la création d’une bibliothèque.
Dans mon entreprise, on utilise Java, et comme notre framework interne doit prendre en charge MySQL, DB2, Oracle et MSSQL, le standard JDBC nous a beaucoup aidés pour la maintenance des adaptateurs propres à chaque base de données.