Déplacement de votre développement JavaScript vers Bash sous Windows

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 code VS et le WSL

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'.

How To Setup Your Dev Directories

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.

Browsing Files From Windows Explorer

There are times when you need to get at a file in Linux from the Windows side. The beautiful thing about the WSL is that you can still do that.

One way is to access the WSL just like a mapped drive. Access it with a \wsl$ directly from the explorer bar:

\wsl$

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.

You can now enable Docker in the WSL by clicking on the item in the system tray and selecting “WSL 2 Tech Preview”:

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.

Source link