Ma boite à outil Node.js

Voilà le genre d’article qui peut servir à tout le monde, et qui peut devenir une formidable opportunité d’échange pour moi si vous venez partager vos propres « batbelt » en commentaire. Donc n’hésitez pas :)

Je travaille au quotidien avec Node.js (à tel point que j’ai presque oublié comment ça marchait côté client ;)), et vous imaginez donc que j’ai des millions d’outils super bien gaulés pour me faciliter la vie au quotidien. Raté ! Il y en a finalement assez peu, et ce sont les grands classiques que vous connaissez déjà probablement. Mais qui sait, si ce n’est pas le cas, ce post pourrait changer un petit bout de votre vie !

Séance bookmarks, c’est parti.

Gestion du code

Côté vomissage de lignes de code, c’est Sublime Text (j’essaie régulièrement les alternatives, c’est vraiment le seul qui a la réactivité et le rendu qui me conviennent) avec quelques plugins :

Pour le versionning c’est évidemment Git, avec les git-extras pour les commandes git ignore et git touch. Parmi mes alias, ce sont ceux-là que j’utilise vraiment tout le temps :

alias gst='git status'
alias ga='git add -p'
alias gc='git commit -v'
alias gco='git checkout'

Je commite toujours mon code avec git add -p ce qui me permet de relire le diff morceau par morceau avant commit, de détecter (et d’ignorer) d’éventuels morceaux de débug oubliés.

Exécution

J’utilise nvm pour installer node et npm :

curl https://raw.githubusercontent.com/creationix/nvm/v0.15.0/install.sh | bash
nvm install 0.11
nvm alias dev 0.11
nvm install 0.10
nvm alias default 0.10
 
# Switch
nvm use default
nvm use dev

Pour exécuter mon code, c’est supervisor :

npm install -g supervisor
 
# lancer un script qui redémarre automatiquement quand je modifie un .js ou .json
supervisor -e 'js,json' -i 'public,test' -- script.js [options]

J’ai joué avec docker sans être convaincu pour l’instant (nvm fait tellement bien le job, et pour les autres services comme les BDDs je n’ai encore pas eu besoin de cohabitation), et j’ai également testé pm2 pour la gestion de process mais sur machine de dév c’est plus encombrant qu’autre chose au final. Par contre je l’utiliserai pour ma prochaine mise en production (jusqu’à présent c’était supervisord ou Phusion Passenger qui tenaient ce rôle).

Debugging

Côté debugging l’écosystème node n’est pas le plus glorieux, mais on a quand-même node-inspector qui fait le taf. On pourra faire de l’analyse pas à pas, poser des breakpoints et même éditer le code directement dans la fenêtre de debugging.

# Installer node-inspector
npm install -g node-inspector
 
# Lancer notre programme en mode debug
node --debug-brk server.js
 
# Lancer le serveur node-inspector
node-inspector
 
# Ouvrir la fenêtre de debugging
x-www-browser 'http://127.0.0.1:8080/debug?port=5858'

Pour faire du profiling (CPU ou HEAP) l’outil le plus proche en terme de facilité d’usage est webkit-devtools-agent. J’ai aussi utilisé heapdump qui génère un fichier dump de la pile pour analyse post-mortem dans Chrome. Globalement le profiling a tendance à me faire pleurer.

Tests

  • Le grand classique mocha
  • Avec le super plugin env-test pour s’assurer que NODE_ENV=test lors de l’exécution
  • supertest est superpratique (ah ah) pour tester une API REST, qui plus est si c’est une application Express

Gestion des dépendances

Évidemment npm fait le job, côté front c’est bower (j’ai testé components et duo, mais je trouve bower plus simple au final) ou browserify (dont il faudra que je vous reparle parce que ça c’est comme les promesses, ça semble compliqué dans la doc et en fait c’est très simple et efficace à l’usage). Mon ~/.npmrc contient quand-même de petites choses utiles :

# Le spinner fout vite la merde dans l'affichage en plus de ne servir à rien
spin = false
 
# Trier les résultats de npm search par date de dernière mise à jour croissante
searchsort = date

Je n’utilise pas de registre alternatif pour l’instant. Les packages du registre EU ne sont pas à jour en général. En dernier recours je pourrais en avoir besoin mais comme c’est très ponctuel je le définis en alias :

alias npmeu="npm --registry http://registry.npmjs.eu"

Ah oui et si vous voulez mettre à jour votre version de npm de temps en temps, un petit npm install -g npm@latest.

J’utilise également david pour surveiller la fraîcheur de mes packages.

Modules

Ce que vous attendiez sûrement le plus, la liste des modules que j’utilise tout le temps :

Je n’ai encore jamais utilisé sérieusement hapi, mais il est dans mes bookmarks quand-même 😉

Il doit y en avoir un million auxquels je ne pense pas sur l’instant, je mettrai sans doute régulièrement cet article à jour.

Dans les trucs qu’il faudrait que je me décide à « npm publish » un de ces jours, il y a aussi :

Un shell aux petits oignons

En bonus, gros coup de cœur pour zsh (auto-complétion façon fuzzy matching) et oh-my-zsh et ses thèmes. Le mien est basé sur « nanotech » :

# Based on nanotech
PROMPT='%F{green}%2c%F{blue} [%f '
# Original RPROMPT
# RPROMPT='$(git_prompt_info) %F{blue}] %F{green}%D{%L:%M} %F{yellow}%D{%p}%f'
# - Add return code (from flazz)
local return_code="%(?..%{$fg[red]%}%? ↵%{$reset_color%})"
# - 24h date format (from tonotdo)
RPROMPT='$(git_prompt_info) ${return_code} %F{blue}] %F{green}%D{%H:%M}%f'
 
ZSH_THEME_GIT_PROMPT_PREFIX="%F{yellow}"
ZSH_THEME_GIT_PROMPT_SUFFIX="%f"
ZSH_THEME_GIT_PROMPT_DIRTY=" %F{red}*%f"
ZSH_THEME_GIT_PROMPT_CLEAN=""

ZSH

J’utilise aussi z, successeur d’autojump que j’utilisais avant (d’où l’alias j=z), qui permet de se déplacer plus facilement dans son arborescence. L’un comme l’autre n’ont pas besoin d’être installés, il suffit d’activer un plugin dans Oh my Zsh :)

À vous !

Voilà, je pense avoir à peu près tout déballé, à vous :)

P.S: je ne suis pas fan des « dotfiles » publiés sur github. Je n’ai jamais trouvé ça utile sans les explications qui vont avec, ce qui explique que non je n’ai pas de dépôt « dotfiles » à vous fournir :)

16 réflexions au sujet de « Ma boite à outil Node.js »

    1. naholyr Auteur de l’article

      Je ne connaissais pas, effectivement ses fonctions « expectJSON* » qui prennent un schéma en paramètre sont intéressantes.

      Répondre
    1. naholyr Auteur de l’article

      Effectivement j’utilise très souvent le module « uuid » (c’est un alias, pas besoin de faire `npm install node-uuid` ;)).

      Je ne suis pas fan des générateurs de squelette, mais je pourrais faire un repo avec l’architecture type de mes projets, pourquoi pas…

      Répondre
      1. Gilles Perreymond

        Je ne suis pas spécialement fan, j’aime trop avoir la main sur mon architecture mais dans le cadre d’une boite à outils ça permet de proposer une squelette type et rapidement testable par les personnes qui passent par ici.

        Répondre
  1. greg

    Quasi pareil ici (mais j’utilise vim).
    Je connaissait pas les modules pour gerer la conf, mais convict va pas tarder à entrer dans la codebase du boulot je sens.

    De temps en temps j’utilises `nodemon`, pour tester des trucs en vitesse. Supervisor fait la meme chose ?

    Je savais pas que z était disponible en plugin zsh, merci du tuyau.

    Répondre
    1. naholyr Auteur de l’article

      Je n’ai jamais utilisé nodemon mais oui c’est exactement le même principe. Nodemon a l’air un peu plus complet, supervisor c’est surtout par habitude je n’ai jamais cherché de remplaçant vu que ça fait le taf 😉

      Répondre
  2. lionelB

    je suis curieux de ton setup sublimelinter / eslint
    Actuellement, je tourne sur jshint gutter (j’aime bien les notif dans le gutter)

    Est ce qu’il est possible d’avoir ce genre de setup avec sublimelinter ?
    Est qu’il y a un interet à switcher d’eslint > jshint ?
    Merci

    Répondre
    1. naholyr Auteur de l’article

      J’utilise vraiment le truc de base, aucune custo à part un .eslintrc par projet après.
      L’exécutable eslint est dans mon install nvm donc j’ai du passer le chargement de nvm dans un .zprofile pour qu’il retrouve son PATH. À part ça rien à signaler.

      J’ai donc laissé les notifs dans le code (cadres rouges autour des warnings), il affiche aussi un point dans la gouttière, je ne sais pas si on peut garder l’un ou l’autre seulement. J’utilise la gouttière pour gitgutter surtout donc ça me gêne pas 😉

      Sinon pour eslint / jshint c’est juste que l’un était plus configurable que l’autre de mémoire, mais c’était un choix assez pifomètrique entre les deux 😉

      Répondre
  3. Nicolab.net (@Nicolab_net)

    Plus ou moins les mêmes choses de mon coté, pour l’essentiel :

    * express

    * winston mais je vais tester bunyan qui a l’air pas mal au niveau des fonctionnalités. Quid des performance, @naholyr niveau perf tu y vois une différence ?

    * error-render pour rendre plus lisible les erreurs et le debug dans la console

    * avant j’utilisais aussi convict pour la conf, maintenant je mets la config dans un container IoC (noder.io) c’est plus pratique

    * bluebird (promesses) pour le flot asynchrone
    * lodash
    * string.js pour manipuler les … string :)
    * moment pour manipuler les dates
    * unit.js et Mocha pour les tests unitaires
    * Gulp pour les tâches

    * Editeur Atom avec jshint, des snippets qui vont bien et tout un tas de packages

    Répondre
    1. naholyr Auteur de l’article

      Pour les perfs de bunyan, je n’ai (bouh, pas bien !) jamais benché. Il faudrait le faire puisqu’un logger est censé tourner souvent et ne pas interférer dans la vitesse d’exécution, mais je n’en ai aucune idée en l’occurrence 😉

      Merci pour error-render j’aime beaucoup son fonctionnement :)

      Répondre
  4. vincezd

    Salut, je découvre ce blog avec plaisir !

    Mieux que autojump ou z, je t’invite à regarder fasd: https://github.com/clvv/fasd
    C’est mieux parce qu’il ne permet pas uniquement de changer de répertoire, mais de lancer d’autres actions sur des fichiers (on peut avoir v pour ouvrir vim, m pour mplayer, ou bien (killer-feature) créer un alias r pour ouvrir le navigateur de fichiers très vim-esque ranger).

    Et pour les emacsiens, qlqs trucs: https://stackoverflow.com/questions/25277748/use-z-jump-around-in-emacs-to-find-directories/25283275#25283275

    Répondre
  5. rougemine

    Merci pour cet article !
    Et concernant les bases de données, tu utilises quoi ? Waterline ? Sequelize ? Bookshelf/Knex ?

    J’ai testé les trois, j’ai bossé sur un projet pro avec le dernier (mais l’ORM Bookshelf n’étant pas relié aux schémas de description des tables de Knex, je n’ai pas été convaincu), mais je serais curieux d’avoir ton retour d’expérience sur la gestion des BDD en Node.js :-)
    (à moins que tu n’utilises que Mongo ?)

    Répondre

Laisser un commentaire