Pourquoi je déconseille WSL

Ce n'est pas que je n'aime pas WSL (Windows Subsystem for Linux) mais je n'aime pas WSL ! 😂

Et ce n'est pas pour rien, ni gratuit, j'ai essayé et je vais vous étayer pourquoi je ne suis pas fan de la solution.

WSL 1 était un émulateur, d'où la lenteur. Mais WSL 2 est une VM qui tourne sur un Hyper-V avec un mapping filesystem bidirectionnel pour l'échange de fichier. En gros, le filesystem est un lecteur réseau sur lequel l'hôte ou la VM peut écrire. C'est pourquoi on a cette sensation que la modification s'effectue en temps réelle depuis Windows ou depuis la VM Linux.

Cette option convient à beaucoup de gens, s'ils font un petit projet Node, manipulent quelques fichiers... ça passe.

Mais ! Attention, moi je vois déjà venir les problèmes et pas des moindres.

Pourquoi WSL me dérange ?

WSL, ce n'est pas un Linux natif, donc, en terme de compatibilité on n'est pas à 100%.

Un détails vous dîtes ? Priez pour ne pas avoir besoin de DKMS et compagnie (très utile pour l'IA au passage).

Ensuite, le mapping de fichier Host <> VM qui fait appel aux watchers de inotify FS peut perdre sa synchro si vous avez trop de fichiers.

Pour simplifier, si vous travailler sur votre Windows avec VSCode et que sur votre VM Linux vous faites tourner l'exécution, votre fichier sur Windows peut être en v0.139 alors que sur la VM il est toujours en v0.138.

Et ce problème de synchro peut aller encore plus loin, si vous ouvrez des projets lourds (Meteor < v3) ou autres framework avec beaucoup de fichiers. Non seulement vous allez passer 30 minutes à build vs 20 secondes en natif mais en plus, cela génère des instabilités et des crashs fréquents !

Des solutions ?

Ce que je vous recommande si vous voulez coder sur votre Windows mais lancer le runtime sous Linux c'est:

• Top 3: Faire tourner une vraie VM sur votre PC au lieu de WSL (privilégiez un Virtual Box ou autre)
• Top 2: Utilisez un Linux natif mais désynchro avec un besoin de faire un git pull entre chaque mise à jour côté Windows
• Top 1: Utilisez un Linux natif et synchro sur un second PC avec un SSH ou un RustDesk en remote. Et avec les outils VSCode actuels, on peut facilement coder à distance sur un projet hébergé sous Linux.

Cela parait anodin mais quand on a poncé WSL dans tous les sens et qu'on a déjà atteint ses limites, on ne peut forcément pas le recommander. C'est d'ailleurs pourquoi je ne conseille à aucun moment d'utiliser Docker Desktop car cette solution s'appuie également sur WSL donc est limitée de la même façon.

En espérant vous éviter des bévues. En attendant, bon code !