Nub - boîte à outils tout-en-un de type Bun pour Node.js

 (github.com/nubjs)
2 points par GN⁺ 5 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Boîte à outils tout-en-un qui complète Node.js sans le remplacer, écrite en Rust et offrant une expérience de développement proche de Bun au-dessus du node standard
  • Regroupe en un seul outil l’exécution de fichiers et de scripts, l’installation des dépendances et la gestion des versions de Node, sans nouveau runtime, sans API propriétaires dépendantes d’un fournisseur, ni lock-in
  • Exécuteur de fichiers nub <file> — exécute .ts, .tsx, etc. sans étape de build, compatible node flag pour flag et variable pour variable, avec un démarrage 2,9× plus rapide que tsx
    • Prise en charge complète de TypeScript (enum, namespace), JSX/TSX, Decorators, chargement automatique de .env*, chargeurs intégrés pour .yaml, .toml, .json5, etc.
    • Détection et installation automatiques de la version de Node attendue par le projet (références à .node-version, .nvmrc, package.json#engines, etc.)
  • Exécuteur de scripts nub run — remplaçant direct de npm/pnpm run, avec un binaire Rust sans démarrage JS propre offrant un dispatch environ 24× plus rapide que pnpm run (14.7ms vs 442.7ms)
    • Prise en charge complète des hooks pre/post, de --filter, --parallel des workspaces pnpm, etc.
  • Exécuteur de paquets nubx — remplaçant direct de npx et pnpm dlx, supprimant le coût du double lancement de Node pour une exécution environ 19× plus rapide que npx (11ms vs 226ms)
  • Gestionnaire de paquets nub install — basé sur le moteur Aube, compatible avec les flags de pnpm, 2,5× plus rapide que pnpm et 3,7× plus rapide que npm
    • Politique de sécurité par défaut intégrée — blocage de postinstall, vérification des paquets malveillants via osv.dev, refus du downgrade de provenance, minimumReleaseAge de 24 heures
    • Fonctionne en compat-mode, avec détection automatique des lockfiles et configurations npm/pnpm/Yarn/Bun
  • Gestionnaire de versions Node nub node — fournit des commandes de gestion manuelle comme install, ls, uninstall, pin, etc.
  • Méta-gestionnaire de paquets nub pm — assure le rôle de Corepack en Rust natif, avec enregistrement de shims globaux npm, yarn, pnpm
  • Licence MIT

À lire aussi

1 commentaires

 
GN⁺ 5 시간 전
Avis Hacker News

  • L’idée est vraiment bonne et tient la route. Bun apporte davantage de choses, comme des drivers de base de données, mais l’expérience développeur fait clairement aussi une grande partie de son attrait
    À noter que l’auteur principal de Nub est Colin McDonnell, le créateur de Zod, et qu’il a aussi travaillé chez Bun à une époque

    • Exact. Nub n’ajoute volontairement aucune API spécifique à Nub : aucun objet global Nub, aucun module intégré avec le préfixe nub:, aucun fichier de config ou lockfile nommé Nub, aucun champ nub dans package.json, aucune variable d’environnement NUB_
      Je pense qu’il vaut mieux que la plupart des ajouts de Bun soient de vraies dépendances

  • C’est surprenant d’utiliser un hook --require plutôt que --import. Ça a peut-être beaucoup changé depuis la dernière fois que j’ai regardé pour créer une fonctionnalité similaire, mais je me demande s’il n’y a pas quelques subtilités dans le support ESM de Nub
    À l’époque, --import de Node n’en était qu’à ses débuts, et il y avait plusieurs cas limites que l’approche ESM-vers-CJS courante gérait comme on le voulait. La plupart étaient sans doute très niche, mais je pense que le top-level await affecterait une part non négligeable des utilisateurs concernés

    • C’est utilisé pour l’enregistrement du préchargement uniquement pour des raisons de performance. Dans ce cas précis, comme dans beaucoup d’autres, CommonJS reste plus rapide qu’ESM. --require ajoute environ 0,5 ms de surcoût, alors que --import est autour de 4,6 ms sur un Macbook Pro M1
      À ce sujet, Node.js a récemment introduit en 2025 module.registerHooks(), une version synchrone de l’API d’enregistrement des hooks de résolution, afin d’améliorer les performances par rapport à l’ancienne API asynchrone module.register(). Ça a levé un obstacle important pour Nub. Pour ceux que ça intéresse, l’API asynchrone ajoutait un coût fixe d’enregistrement de 19 ms, plus environ 130 us de surcoût supplémentaire par import
      Les flags utilisés par Nub ici n’ont absolument aucun impact sur le code utilisateur, et le top-level await est pris en charge partout où Node.js lui-même le prend en charge

  • On vient tout juste de merger une PR pour migrer tout notre monorepo vers nub
    Zéro problème, et c’est incroyablement rapide

    • Vous avez merger une PR pour migrer un monorepo partagé vers ça moins d’une heure après la publication ?

  • Node ne peut pas exécuter du TypeScript depuis quelques versions déjà ? Pourquoi aurait-on besoin d’un transpileur ?

    • Le support TypeScript intégré de Node ne fait que supprimer les types. Ça fonctionne avec une très grande partie de la syntaxe TypeScript, mais pas avec tout. Il ne vérifie pas réellement les types, il les enlève juste pour permettre l’exécution. On perd aussi des choses comme tsconfig
      Celui-ci semble prendre en charge à la fois l’approche intégrée d’effacement et un vrai traitement TypeScript
    • L’équipe Node.js a retiré --experimental-transform-types dans Node.js v26. Cela rend impossible un support natif complet de TypeScript
      https://github.com/nodejs/typescript/issues/51#issuecomment-...
    • Il est indiqué qu’il injecte des polyfills si nécessaire pour des API comme Worker ou Temporal

  • Le README dit que le support WebSocket est natif à partir de Node 22, mais Node n’a pas de bibliothèque WebSocket native. Le lien vers le standard WebSocket pointe vers MDN, qui ne décrit que l’interface utilisateur WHATWG, pas le protocole ni le fonctionnement de WebSocket
    On a l’impression qu’il manque quelque chose, ou qu’une bibliothèque non native est utilisée en complément

    • Depuis la version 22, Node prend en charge un client WebSocket intégré, mais pas de serveur

  • Il est respectable de partir de la technologie existante et de ne pas en refaire une version inférieure. Si tous les efforts consacrés à créer des alternatives avaient été investis dans Node, je me demande jusqu’où on en serait aujourd’hui avec un leadership adapté

    • Vous vous souvenez peut-être du fork io.js de Node.js en 2014. Quand Node stagnait, plusieurs personnes ont forké vers io.js, qui a finalement été réintégré dans Node et l’a remis sur les rails. En remontant encore plus loin, CoffeeScript, qui était lui aussi en quelque sorte un « fork » de JS, a vu ses meilleures idées absorbées par ES5
      Une petite équipe agile peut valider de bonnes idées parce que l’échec n’est pas un risque existentiel. Bref, les forks font partie d’un écosystème sain
    • Il y a fondamentalement beaucoup de choses qu’on ne peut pas corriger avec cette approche
      Exemple simple : Node est le seul logiciel open source sérieux que je connaisse où il n’existe aucun moyen de documenter la configuration dans le fichier de config. C’est absurde. Côté Node, ils ont adopté JSON sans réfléchir, puis ont refusé d’envisager toute alternative ensuite, y compris un simple « JSON avec commentaires »
      Quand une organisation se fige dans de mauvaises décisions, la seule manière de corriger le tir est de repartir de zéro. Tant que tout le monde continuera à empiler des choses sur Node, l’écosystème JS entier restera incapable de laisser de la documentation dans sa configuration
      Il y a plusieurs problèmes de ce genre dans l’écosystème Node, et cette absurdité totale autour de l’impossibilité de documenter la configuration n’est qu’un de mes griefs personnels

  • Fan de Nub et de sa mascotte nubnub. Plus sérieusement, c’est un excellent projet, assez intéressant, et je l’utilise depuis la semaine dernière, ou en tout cas depuis sa mise en ligne publique

  • Astucieux. Si c’est déjà écrit en Rust, on ne risque pas de se lancer dans une migration vers Rust en vibe coding pour ensuite perdre tous ses clients ;)

    • Après le rachat par OpenAI, ils referont sûrement le projet en Zig
    • Ce projet contient déjà une bonne part de vibe coding. Le deuxième contributeur du dépôt, c’est Claude
    • « Si c’est déjà codé en Rust à grand renfort de vibe coding » serait peut-être plus juste. Nub dégage quand même pas mal cette impression dans l’ensemble. Ça ne me dérange pas, mais c’est drôle comparé à Bun
      Cela dit, l’hystérie anti-IA autour de Bun est vraiment triste, et donne parfois même l’impression d’une campagne coordonnée
    • C’est encore plus utile si, de toute façon, c’est déjà du vibe coding et qu’il n’y a pas de clients au départ
    • Oui. Je ne vois pas bien ce que le fait que ce soit « écrit en Rust » apporte ici. J’ai l’impression qu’on pourrait obtenir la même chose avec quelques scripts shell et un package.json