Voici une note pour présenter la seconde #iteration du Projet 32 - "POC serveur Git HTTP avec exécution de scripts au push".

J'ai tout d'abord implémenté dans ce commit un mécanisme qui exécute du code JavaScript automatiquement après chaque git push.

Pour cela, j'ai choisi de me baser sur le mécanisme Server-Side Hooks natif de Git : post-receive.

Voici le contenu de ce script hook en Bash :

#!/bin/bash

while read oldrev newrev refname; do
	branch=$(git rev-parse --symbolic --abbrev-ref $refname)

	curl -X POST \
	  -H "Content-Type: application/json" \
	  -d "{
		\"oldrev\": \"${oldrev}\",
		\"newrev\": \"${newrev}\",
		\"refname\": \"${refname}\",
		\"branch\": \"${branch}\",
		\"repository\": \"$(basename $(pwd))\"
	  }" \
	  "${POST_RECIEVE_HOOK_URL}" >> /dev/null
done

Chaque événement git push déclenche un appel HTTP vers le endpoint http://localhost:3334/post_recieve_hook_url/ exposé par le serveur NodeJS. Le payload contient notamment :

• oldrev : l'identifiant du dernier commit présent dans le repository avant le push
• newrev : l'identifiant du commit le plus récent envoyé lors du push

L'intervalle entre oldrev et newrev permet d'identifier précisément l'ensemble des commits qui ont été poussés lors de cette opération.

J'ai ensuite implémenté une version SvelteKit iso-fonctionnelle de node-git-http-server. Voici le repository poc-node-git-server-in-sveltekit .

Contrairement à ce que j'avais prévu initialement, pour cette implémentation, je ne me suis pas basé sur SvelteKit Custom Server, mais sur la fonctionnalité Server hooks : src/hooks.server.js#L11.

Je viens de publier la première #iteration du Projet 32 - "POC serveur Git HTTP avec exécution de scripts au push" dans le repository node-git-http-server.

L'implémentation d'un serveur Git HTTP via Apache ou nginx, en s'appuyant sur git-http-backend , paraît plutôt simple à réaliser.

Comme mon objectif est d'intégrer cette fonctionnalité dans le projet sklein-pkm-engine et que j'ai une préférence pour les monolith, j'ai exploré les solutions basées sur NodeJS.

J'ai dans un premier temps étudié le projet node-git-http-server et ensuite node-git-server.

Ces deux projets semblent peu actifs.
J'ai échoué à faire fonctionner le projet node-git-server, probablement à cause d'une erreur de ma part — j'ai sans doute oublié d'initialiser au préalable les dépôts Git en mode bare.

Par la suite, en utilisant Claude Sonnet 4, j'ai créé une implémentation basée uniquement sur les modules natifs de NodeJS et l'exécutable git-http-backend , sans recourir à aucun package NodeJS externe.

Voici le résultat : node-git-http-server/server.js.

Prochaines étapes

• Implémenter un système qui exécute du code JavaScript automatiquement après chaque git push, en lui transmettant la branche concernée et la liste des nouveaux commits publiés.
• Implémenter une déclinaison de ce projet dans un SvelteKit Custom Server.

Le 18 avril 2012, je publiais sur LinuxFr le journal qui suit — il recueillit 91 commentaire (lien https://linuxfr.org/users/harobed/journaux/reflexions-a-propos-de-nodejs-et-de-javascript-plus-globalement)

Bonjour,

Cela fait quelques jours que je me pose la question suivante : « Est-ce que Node.js ne va pas devenir une technologie incontournable / majeure dans les 2 ans qui viennent ? »

Le contexte

Je suis développeur Python depuis de nombreuses années. J'aime ses librairies, j'aime ses outils, j'aime sa communauté.
J'aime tellement sa syntaxe que quand je vois la syntaxe d'autres langages, j'ai une réaction quelque peu épidermique à la lecture du code.
Avec le temps, l'habitude de la syntaxe Python minimaliste, proche d'un pseudo-code, rend difficile la possibilité d'apprécier un autre langage. Je ne sais pas si c'est positif ou négatif, je me pose simplement la question. Enfin, ceci est un autre sujet.

Cependant, mon regard se tourne de plus en plus vers Node.js… je n'ai pas franchi le pas, je n'ai rien développé en Node.js… mais je me demande si je ne passe pas à côté de quelque chose d'important.

Les forces de Node.js

• Bien que Node.js date seulement de 2009 :

  • il a déjà un bon système de paquets : Node Package Manager, que la grande majorité de la communauté semble utiliser
  • il a déjà une très forte communauté, de très nombreuses librairies — exemple : plein de librairies classées, déjà plus de 9 000 paquets sur npm
  • de plus en plus de sociétés semblent l'utiliser

• Tous les développeurs web (front-end) connaissent le langage, il est très populaire. Par conséquent, pour passer à Node.js il n'y a pas le frein d'apprendre un nouveau langage, comme ce serait le cas avec l'utilisation d'un framework web basé sur Ruby ou Python. Je pense que dans les mois qui viennent, de nombreux développeurs PHP vont passer à Node.js… surtout ceux qui regardaient ailleurs mais qui ne souhaitent pas apprendre un nouveau langage.

• La possibilité de partager du code (librairies communes…) entre la partie client et serveur peut être intéressante. La question se pose de plus en plus, étant donné qu'on est de plus en plus amené à effectuer beaucoup de traitements côté client (exemple avec Backbone.js).
  Dernièrement, dans tous mes projets de développement web, j'ai utilisé un moteur de template côté client en plus du moteur de template côté serveur.
  Je dois gérer de plus en plus souvent une couche modèle côté client, des vues côté client… Cela fait donc plein d'éléments en double, utilisés une fois sur le serveur, une fois sur le client. Donc deux technologies à maîtriser.
  Ces derniers jours, la visualisation du screencast du framework JavaScript Meteor m'a mis la puce à l'oreille.
  Autre exemple : il est possible d'utiliser la même API Canvas côté client et côté serveur (avec node-canvas).

• Node.js semble être très rapide et tient très bien la montée en charge.

• La vitesse de l'interpréteur JavaScript est en constante progression : V8 (JavaScript engine)

Faiblesses de Node.js

Je ne sais pas si mes remarques sont exactes, je n'ai aucune expérience en Node.js.

• Par exemple, dans la partie Bad Use Cases du guide Felix's Node.js Convincing the boss guide, il est indiqué que les frameworks Node.js sont moins matures que ce que l'on peut trouver en Ruby, Python et PHP (bon, pour ce dernier j'ai des doutes — je pense que la communauté Node.js est déjà plus mature, plus structurée que la communauté PHP… enfin bon…).
• Je ne pense pas que Sequelize soit aussi mature que SQLAlchemy.
• Je n'ai pas trouvé d'outil comme Whoosh en JavaScript (c'est un moteur de recherche léger). J'ai tout de même trouvé Node-xapian.

Je ne sais pas s'il est encore tôt pour passer à Node.js, mais si la communauté continue à être aussi dynamique que ces 2 dernières années… alors les pièces manquantes seront bientôt créées.

Est-ce que l'on va retrouver JavaScript partout ?

Voici une petite liste :

• JavaScript dans les navigateurs web
• JavaScript côté serveur (Node.js)
• JavaScript dans Qt : Introduction QML + Qt Quick, qui semble vraiment très puissant
• Les possibilités d'utiliser GTK + JS : gjs and Gtk+
• GNOME Shell est en grande partie développé en JavaScript. Ses extensions sont entièrement développées en JS.
• Sur mobile : WebOS et Boot to Gecko

Quand je vois cette liste, je me pose sérieusement la question : est-ce que JavaScript est le langage incontournable de ces 10 prochaines années ? Certes, il est déjà incontournable dans le navigateur, mais pour le reste ?

Dépôt GitHub : https://github.com/pyodide/pyodide

Dépôt GitHub : https://github.com/kelektiv/node-cron/

Site officiel : https://www.passportjs.org/