Déplacement de votre développement JavaScript vers Bash sous Windows
À propos de l'auteur
Burke Holland est un développeur front-end basé à Nashville, dans le Tennessee; la plus grande ville du monde. Il apprécie beaucoup JavaScript car c’est le seul moyen pour lui… Plus d'informations sur Burke Hollande …
Vous aimez votre terminal Bash mais vous aimez aussi votre PC? Vous avez peut-être surveillé certains des nouveaux équipements Surface, mais vous ne pouvez pas effectuer le changement sans votre terminal. Maintenant, vous pouvez avoir Windows et Bash. Dans cet article, nous allons examiner en détail comment configurer un boîtier de développement Windows / Linux pour le développement JavaScript.
Je suis l’un de ceux qui ne peuvent pas vivre sans leur terminal Bash. Ce seul fait a rendu difficile le travail de front-end sur Windows. Je travaille chez Microsoft et je suis sur un Mac. Ce n'est que lorsque la nouvelle ligne de matériel Surface est apparue il y a quelques années que je me suis rendu compte: Je dois en avoir un .
Alors j'en ai un. Un Surface Book 2 sous Windows 10 pour être exact. Je suis en train de rédiger cet article à ce sujet. Et que dire de ma douce, douce invite Bash? Bien sûr, je l’ai apporté avec moi.
Dans cet article, je vais examiner en détail comment la nouvelle technologie de Windows 10 vous permet d’exécuter un terminal entièrement Linux sous Windows. Je vais également vous montrer mon incroyable configuration de terminal (nommée "best ever" par "moi") et comment vous pouvez également configurer votre propre machine de développement Windows / Linux.
Si vous avez envie de certains Si ce matériel de Surface ne peut pas vivre sans terminal Linux, vous êtes au bon endroit.
Note : Au moment d'écrire ces lignes, de nombreux éléments de ce Pour utiliser cet article, vous devez utiliser ou passer à des versions "de prévisualisation" ou "internes" de divers éléments, y compris Windows. La plupart de ces éléments figureront dans la version principale de Windows ultérieurement.
Sous-système Windows pour Linux (WSL)
Le sous-système de Windows pour Linux ou "WSL", c’est quoi vous permet d'exécuter Linux sur Windows. Mais qu'est-ce que est exactement cette science folle?
Le WSL, dans sa version actuelle, est une couche de traduction qui convertit les appels système Linux en appels système Windows. Linux s'exécute sur le WSL. Cela signifie que pour obtenir Linux sous Windows, vous devez faire trois choses:
Activez le WSL,
Installez Linux,
Incluez toujours trois éléments dans une liste.
En fin de compte, cette couche de traduction est un peu sur le côté lent – un peu comme moi essayant de me rappeler si j'ai besoin de épissure ou slice . Cela est particulièrement vrai lorsque le WSL lit et écrit dans le système de fichiers. C’est un gros problème pour les développeurs Web, car toute npm install proprement dite copiera des milliers de fichiers sur votre ordinateur. Je veux dire, je ne sais pas pour vous, mais je ne vais pas me mettre à gauche avec mes propres chaînes .
La version 2 du WSL est une autre histoire. Il est considérablement plus rapide que la version actuelle car il exploite un noyau de virtualisation sous Windows au lieu d’utiliser la couche de traduction. Quand je dis que c’est «considérablement plus rapide», j’entends bien, beaucoup plus vite. Aussi vite que moi googler “splice vs slice”.
C'est pourquoi je vais vous montrer comment installer le WSL 2. Au moment de la rédaction de cet article, vous devrez être présent sur la page “Insider ”Build of Windows.
Tout d’abord: suivez ce petit guide pour activer le WSL sous Windows 10 et vérifier le numéro de version de Windows.
Une fois que vous l’avez installé, appuyez sur la touche Windows, puis sur tapez «initié Windows». Choisissez ensuite «Paramètres du programme Windows Insider».
Vous aurez le choix entre deux options de «sonnerie». vouloir être sur. Je sais que beaucoup de gens sont sur le ring rapide. Je suis un gars prudent, cependant. Quand j'étais enfant, je descendais la glissoire du terrain de jeu sur mon ventre en me tenant sur les côtés. C'est pourquoi je reste sur le ring lent. Cela fait plusieurs mois que je suis dessus et je trouve que ce n'est pas plus perturbant ni instable que Windows classique.
C'est une bonne option si vous voulez le WSL 2, mais vous ne voulez pas mourir diapositive.
Ensuite, vous devez activer la fonctionnalité «Plate-forme de machine virtuelle» dans Windows, requise par le WSL version 2. Pour accéder à cet écran, appuyez sur la touche Windows et tapez «fonctionnalités Windows». Sélectionnez ensuite «Activer ou désactiver les fonctionnalités Windows». Sélectionnez «Plateforme de machine virtuelle». L'option “Sous-système Windows pour Linux” devrait déjà être activée.
Ajoutez-le à vos plugins zsh et sourcez le fichier zshrc:
nano ~ / .zshrc
# Dans le fichier .zshrc
plugins (zsh-nvm zsh-autosuggestions git)
source ~ / .zshrc
Le plug-in lit votre historique zsh. Commencez donc à taper une commande que vous avez déjà saisie et observez la magie. Essayez de taper la première partie de la commande de clonage longue ci-dessus.
Si vous appuyez sur ↹ la commande sera complétée automatiquement. Si vous continuez d'appuyer sur ↹ toutes les commandes de votre historique susceptibles de correspondre sont passées en revue.
Raccourcis clavier importants
Certains raccourcis terminaux sont utilisés régulièrement. . Je trouve cela avec tous mes outils – y compris VS Code. Essayer d'apprendre tous les raccourcis est une perte de temps car vous ne les utiliserez pas assez pour vous en souvenir.
En voici quelques-uns que j'utilise régulièrement:
Terminal Shortcut
Que fait-il? ] Ctrl + L
Ceci efface le terminal et vous ramène au sommet. C'est l'équivalent de taper «clear».
Ctrl + U
Ceci efface uniquement la ligne actuelle.
Ctrl + A
Déplace le curseur. jusqu'au début de la ligne de commande.
Ctrl + E
Passe au bout de la ligne.
Ctrl + K
Supprimez tous les caractères. après le curseur.
Ça y est! Tout le reste que j’ai probablement appris, puis oublié, car il n’a jamais été utilisé.
Configuration de Git (Hub / Lab / Whatevs)
Git s’applique sous Ubuntu, aucune installation n’est donc requise. Vous pouvez suivre les instructions auprès de l’organisateur de votre choix pour obtenir vos clés ssh créées et fonctionnelles.
Notez que dans les instructions Github, il vous est conseillé d’utiliser l’utilitaire «copy» pour copier vos fichiers. clé ssh. Ubuntu a la commande “xcopy”, mais cela ne fonctionnera pas ici car il n'y a pas d'interopérabilité entre Linux et Windows en termes de presse-papier.
A la place, vous pouvez simplement utiliser l'exécutable du Presse-papier Windows et l'appeler directement depuis le Terminal. Vous devez d'abord obtenir le texte avec cat puis le diriger vers le presse-papiers de Windows.
cat ~ / .ssh / id_rsa.pub | clip.exe
Les Github docs vous disent de vous assurer que le ssh-agent est en cours d'exécution. Ce n'est pas. Vous verrez ceci lorsque vous essayez d'ajouter votre clé à l'agent:
Vous pouvez démarrer l'agent. , mais au prochain redémarrage de Windows ou de l’arrêt du WSL, vous devrez le redémarrer. En effet, il n'y a pas de système d'initialisation dans le WSL. Il n'y a pas de systemd ni aucun autre processus qui lance tous vos services au démarrage du WSL. WSL est toujours en avant-première et l’équipe cherche une solution à ce problème.
Entre-temps, qu’il n’y en ait pas encore un plugin zsh. Il s'appelle ssh-agent et il est installé avec oh-my-zsh, il vous suffit donc de le référencer dans le fichier .zshrc .
zsh-nvm zsh-autosuggestions ssh-agent git
Ceci démarrera automatiquement ssh-agent s’il ne s’exécute pas la première fois que vous lancez le WSL. L’inconvénient est qu’il va vous demander votre phrase secrète à chaque démarrage de WSL. Cela signifie essentiellement à chaque fois que vous redémarrez votre ordinateur.
Le WSL n’a pas Interface graphique, vous ne pouvez donc pas installer un outil visuel comme VS Code. Cela doit être installé du côté Windows. Cela pose un problème car un programme fonctionnant du côté Windows accédant à des fichiers du côté Linux, il peut en résulter tous les problèmes de bizarrerie et de «permission refusée». En règle générale, Microsoft vous recommande de ne pas modifier les fichiers du côté WSL avec des programmes Windows.
Pour résoudre ce problème, il existe une extension pour VS Code appelée " Remote WSL [ ”. Cette extension est faite par Microsoft et vous permet de développer au sein du WSL, mais à partir de l'intérieur de VS Code.
Une fois l'extension installée, vous pouvez attacher le code VS directement au côté Ubuntu en ouvrant la palette de commande ( Ctrl + Maj + P) et sélectionnez “Remote-WSL: Nouvelle fenêtre”.
Ceci ouvre une nouvelle instance de VS Code qui vous permet de travailler comme si vous étiez complètement du côté Linux. Faire «Fichier / Ouvrir» parcourt le système de fichiers Ubuntu au lieu de Windows
Le terminal intégré dans le code VS ouvre votre configuration zsh magnifiquement personnalisée. Tout "fonctionne" comme il se doit lorsque l'extension WSL distante est installée.
Si vous ouvrez du code à partir de votre terminal avec le code . VS Code détectera automatiquement qu'il a été ouvert à partir du WSL, et joindra automatiquement l'extension WSL distante.
Extensions VS Code avec WSL distant
L'extension WSL distante pour VS Code fonctionne en configurant un petit serveur côté Linux, puis en se connectant à celui-ci à partir de VS Code sur le côté Windows. Dans ce cas, les extensions que vous avez installées dans VS Code ne sont pas automatiquement affichées lorsque vous ouvrez un projet à partir du WSL.
Par exemple, un projet Vue est ouvert dans VS Code. Même si toutes les extensions Vue appropriées sont installées pour la coloration syntaxique, le formatage, etc., VS Code agit comme si aucun fichier .vue n'avait jamais été vu auparavant.
Toutes les extensions que vous avez installées peuvent être activées dans le WSL. Il vous suffit de trouver l'extension souhaitée dans le WSL, puis de cliquer sur le bouton «Installer dans WSL».
Toutes les extensions installées dans le WSL apparaîtront dans leur propre section dans la vue Explorateur d'extensions. Si vous avez beaucoup d'extensions, il peut être légèrement gênant d'installer chacune d'elles individuellement. Si vous souhaitez simplement installer chaque extension que vous avez dans le WSL, cliquez sur la petite icône de téléchargement dans le nuage située en haut de la section 'Local – Installed'.
This is already an opinionated article, so here's one you didn't ask for on how I think you should structure your projects on your file system.
I keep all my projects on the Linux side. I don’t put my projects in “My Documents” and then try and work with them from the WSL. My brain can’t handle that.
I create a folder called /dev that I put in the root of my /home folder in Linux. Inside that folder, I create another one that is the same name as my Github repo: /burkeholland. That folder is where all of my projects go — even the ones that aren’t pushed to Github.
If I clone a repo from a different Github account (e.g. “microsoft”), I’ll create a new folder in “dev” called /microsoft. I then clone the repo into a folder inside of that.
Basically, I’m mimicking the same structure as source control on my local machine. I find it far easier to reason about where projects are and what repos they are attached to just by virtue of their location. It’s simple, but it is highly effective at helping me keep everything organized. And I need all the help I can get.
You might do this for a number of different reasons. For instance, just today I needed a Chrome extension that isn’t in the web store. So I cloned the repo in WSL, then navigated to it as an “Unpacked Extension” and loaded it into Edge.
One thing that I do with some frequency in Linux is to open the directory that contains a file directly from the terminal. You can do this in the WSL, too, by directly calling explorer.exe. For instance, this command opens the current directory in Windows Explorer.
$ explorer.exe .
This command is a bit cumbersome though. On Linux, it’s just open .. We can make that same magic by creating an alias in the ~/.zshrc.
alias open="explorer.exe"
Docker
When I said all tooling should be on the Linux side, I meant that. That includes Docker.
This is where the rubber really starts to meet the road. What we need here is Docker, running inside of Linux running inside of Windows. It’s a bit of a Russian Nesting Doll when you write it down in a blog post. In reality, it’s pretty straightforward.
You’ll need the correct version of Docker for Windows. As of the time of this writing, that’s the WSL 2 Tech Preview.
When you run the installer, it will ask you if you want to use Windows containers instead of Linux containers. You definitely do. Otherwise, you won’t get the option to run Docker in the WSL.
After you start the service, you can use Docker within the WSL just as you would expect to be able to. Running Docker in the WSL provides a pretty big performance boost, as well as a boost in cold start time on containers.
Might I also recommend that you install the Docker extension for VS Code? It puts a visual interface on your Docker setup and generally just makes it easier to work with Docker because you don’t have to remember all those command-line flags and options.
Get More Bash On Windows
At this point, you should get the idea about how to put Bash on Windows, and how it works once you get it there. You can customize your terminal endlessly and there are all sorts of rad programs that you can add in to do things like automatically set PATH variables, create aliases, get an ASCII cow in your terminal, and much more.
Running Bash on Windows opened up an entirely new universe for me. I’m able to combine Windows which I love for the productivity side, and Linux which I depend on as a developer. Best of all, I can build apps for both platforms now with one machine.
Further Reading
You can read more about Bash on Windows over here:
Special thanks to Brian Ketelsen, Matt Hernandez, Rich Turner, and Craig Loewen for their patience, help, and guidance with this article.