Depuis l’ouverture du blog, sur les articles en cours d’écriture et les articles déjà publiés, j’avais remarqué que la coloration syntaxique des blocs de code ne semblait pas supporter les langages dont je voulais parler (ce qui est un peu cocasse pour un blog tech vous en conviendrez). J’ai donc pris mon courage à deux mains et j’ai trouvé une solution. Vu qu’elle est simple, élégante et que je souhaite m’en souvenir dans le cas où j’ai besoin d’ajouter d’autres langages sur le blog, j’en écris un article (bah oui, les articles c’est aussi pour moi).

Le problème

Comme expliqué dans l’article d’ouverture du blog, ce blog fonctionne avec le générateur de site statique Hugo et le thème Hello Friend. Comme beaucoup de thèmes disponibles sur le net pour Hugo, Hello Friend supporte nativement la coloration syntaxique des blocs de code. Pour ce faire, il s’appuie sur Prism.js.

Prism.js est une librairie qui dispose d’une grande communauté de contributeurs, ce qui lui permet d’avoir un support des langages assez exhaustif (297 languages supportés à l’heure ou j’écris ses lignes). Malheureusement, avoir autant de languages supportés a un coût non négligeable sur le poids total de la librairie. Ainsi, pour limiter l’impact de celle-ci sur nos sites internet, il faut choisir les langages que l’on souhaite pouvoir utiliser. Et c’est à ce moment très précis que nous avons un problème : le développeur du thème que j’utilise a préféré mettre applescript et visual basic à dart.

Pour régler cela, je pourrais modifier les fichiers du thème directement et réimporter la librairie avec les bons langages séléctionnés ; mais cela n’est pas, je pense, une solution optimale.

  • Cela empêche de profiter des mises à jour du thème.
  • Le thème est importé via un submodule git et n’est donc pas à proprement parler dans le repo du blog. J’aimerais conserver ce fonctionnement.

La solution

Après quelques recherches, je me suis rappelé de l’existence d’un mécanisme assez élégant d’Hugo que j’utilise déjà pour mettre en place les analytics. Je vais appeler cela la surcharge de thème (Je ne sais pas si cela a un nom officiel mais je trouve que ça match parfaitement avec le fonctionnement, alors appelons-le comme ça 😅).

Afin de pouvoir comprendre ce fonctionnement, jetons un oeil à la hierachie de dossier de notre thème.

$ tree themes/hello-friend/ -d
themes/hello-friend/
├── assets
│   ├── css
│   ├── fonts
│   └── js
├── exampleSite
│   ├── content
│   │   └── post
│   └── static
│       └── img
├── images
├── layouts
│   ├── _default
│   │   └── _markup
│   ├── archive
│   ├── partials
│   └── shortcodes
└── static
    └── img

19 directories

Les fichiers de la librairie Prism.js que nous souhaitons update se trouvent dans :

  • /assets/css/prism.scss
  • /assets/js/prism.js

Pour remplacer ces fichiers par nos fichiers à nous, rien de plus simple : nous allons créer à la racine du projet Hugo la même hierarchie de dossier et mettre nos fichiers à nous. Ainsi, quand Hugo aura besoin du dit fichier, il prendra ceux-là car plus haut dans la hierarchie.

Cela me rappelle un peu le système d’héritage de thème de Magento où l’on pouvait créer des thèmes enfants afin d’avoir plusieurs versions pour les différents événements de l’année (Soldes, Noël, Paques, Fête des Mères / Pères, …) et c’était très utile dans le contexte des sites ecommerces des clients que nous avions. Il m’arrive d’ailleurs assez régulièrement de regretter ce système : pourquoi ne retrouve-t-on pas cela plus souvent sur les CMS actuels du marché ?

Voilà, maintenant le blog supporte la coloration syntaxique sur les langages dont nous allons avoir besoin pour nos articles et, surtout, nous allons pouvoir continuer de bidouiller. Comptez sur moi pour ça !