I came back to Windows from macOS and used PowerShell Core because it said, "Command prompt, at least PowerShell." By the way, I remembered that there was WSL (Windows Subsystem for Linux). I decided to use WSL entirely for the development environment, so make a note of the procedure.
The development environment here means developing the front end of the web application with Angular and the back end with node.js (and since I am not really familiar with Linux, WSL, distribution and shell I am confident that it is confused with.)
Introduce WSL by referring to.
Windows Terminal is a terminal client for Windows, and although it is still in the Preview version, I love it because it is easy to use and highly customizable.
When you install WSL, you will also see an additional Profile called "Ubuntu" in Windows Terminal.
To have Ubuntu Terminal open by default when you start Windows Terminal, press ctrl +, to open profiles.json and change defaultProfile.
Other,
colorScheme to change the color to make it easier to see startingDirectory keybindings so that you can copy and paste with ctrl + c and ctrl + v (by default ctrl + shift + c / v)Is changing. Windows Terminal is fun because you can customize it in various ways by editing this profiles.json. For reference, I will post my settings.
profiles.json
{
"$schema": "https://aka.ms/terminal-profiles-schema",
"defaultProfile": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"profiles":
[
<Omitted>
{
"guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"hidden": false,
"name": "Ubuntu",
"colorScheme": "Campbell",
"cursorShape": "emptyBox",
"acrylicOpacity": 0.85,
"useAcrylic": true,
"cursorColor": "#FFFFFF",
"fontFace": "Cascadia",
"fontSize": 12,
"startingDirectory": "C:\\dev",
"source": "Windows.Terminal.Wsl"
}
],
"schemes": [
{
"name": "Campbell",
"foreground": "#F2F2F2",
"background": "#0C0C0C",
"colors": [
"#0C0C0C",
"#C50F1F",
"#13A10E",
"#C19C00",
"#0037DA",
"#881798",
"#3A96DD",
"#CCCCCC",
"#767676",
"#E74856",
"#16C60C",
"#F9F1A5",
"#3B78FF",
"#B4009E",
"#61D6D6",
"#F2F2F2"
]
}
<Omitted>
],
// Add any keybinding overrides to this array.
// To unbind a default keybinding, set the command to "unbound"
"keybindings": [
{ "command": "copy", "keys": [ "ctrl+c" ] },
{ "command": "paste", "keys": [ "ctrl+v" ] }
]
}
With the introduction of WSL, "wsl" has also increased in the Terminal of Visual Studio Code, so change it to "wsl" with ctrl + shift + p → Terminal: Select default shell.
It seems that you can switch Terminal for each workspace by specifying Terminal in .code-workspace, but I don't recommend it because there are some environments where wsl is not included.
Even if I change VScode's Default Terminal to WSL, VScode's tasks seem to be executed on the Windows side, and I want to run them on WSL as well. Unfortunately, to solve this, you need to write "WSL-dependent tasks".
./vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "ng-serve",
"type": "shell",
"isBackground": true,
"command": "ng serve",
"problemMatcher": {
"owner": "custom",
"pattern": {
"regexp": "^$"
},
"background": {
"activeOnStart": true,
"beginsPattern": ".*Angular Live Development Server.*",
"endsPattern": ".*Compiled successfully.*"
}
}
},
{
"label": "ng-serve-wsl",
"type": "shell",
"isBackground": true,
"command": "\"ng serve\"",
"options": {
"shell": {
"executable": "C:\\Windows\\System32\\wsl.exe",
"args": [ "bash -ic" ]
}
},
"problemMatcher": {
"owner": "custom",
"pattern": {
"regexp": "^$"
},
"background": {
"activeOnStart": true,
"beginsPattern": ".*Angular Live Development Server.*",
"endsPattern": ".*Compiled successfully.*"
}
}
}
]
}
For example, the tasks.json example above defines a task called ng-serve for debugging Angular, but since it works on Windows, In addition, we also have a task called ng-serve-wsl with settings to run on WSL.
The difference between the WSL version is the information of wsl.exe set in `ʻoptions: {} ``, which is the command prompt.
wsl.exe bash -ic "ng serve"
Is equivalent to executing.
The important thing is the bash execution argument -i, otherwise .bashrc will not be read (= PATH is not set) and ng will result in a command not found error. I will end up.
Tools necessary for development such as git, node, npm, angular, python, aws-cli, firebase-cli will be put in WSL. For Ubuntu, it is usually installed with apt-get.
I was wondering if I should wait until WSL2, but it was very convenient to use it with WSL1 as well.
Terminal and VSCode, which are often used during development, can now be spent almost without being aware that they are Windows. The scripts etc. are almost the same as macOS, and it is easier to rehearse CI running on Linux.
The interoperability with Windows is higher than I expected, and if I add .exe to the command, I can execute Windows commands even from WSL, so I felt that I could reach the itchy place (from WSL). You should be able to build .NET apps that only work on Windows by hitting msbuild.exe, and of course you can check the operation of .NET programs that run cross-platform by putting .NET Core on the WSL side in the first place. Is possible).
As a bit redundant,
Sometimes I hit the git command in bash, sometimes I use a Git client app (such as GitKraken or VSCode), and I know how to make the credential store common. I don't have it, so I'm memorizing it in both for now.
In order to "copy the pathname in Windows Explorer and cd in bash", you need a command similar to the following:
cd $(wslpath -u "C:\dev\hoge")
I can convert a Windows path string to a UNIX path with the wslpath function, so I'm biting it and moving the directory.
Therefore, if you need to write a script on the assumption that it will work in their environment, you will have to use PowerShell together to check the operation, and eventually you will have to install node on the Windows side as well. Well, this is a team situation. Still, Windows Terminal is easy to use because you can manage both WSL and PowerShell in tabs.
Assuming VSCode, by using Remote --WSL Extension, all project development can be done on WSL. You will be able to do it. The Terminal described above and the task execution are all.
Currently, it is still a Preivew version, so stability is uncertain, WSL seems to be slow (subjective) because it is a remote premise, VS Code extension needs to be installed for remote depending on the thing, etc. I was a little worried, so I tried it a little and put it on hold.
Recommended Posts