This article was originally posted on December 21st 2018 at: https://nickjanetakis.com/blog/a-linux-dev-environment-on-windows-with-wsl-docker-tmux...
For further actions, you may consider blocking this person and/or reporting abuse
Over the last 6 years I professionally develop using:
I can say that WSL is not ready for professional use and all developer technologies will be limited on Windows because the lack of adoption.
Everything else than Linux and maybe Mac are just a shadow, trying to mimic a Linux env, and this choice will byte your as* in the future, and you will spend many days trying to fix a dependency, a missing feature, an issue that the library developers will not fix because they do not use Windows/WSL.
Just my 1 cent.
I suppose it depends on what you're working with.
For me WSL has been fantastic for developing web apps with the following tools:
Rails, Flask, Django, Node, Phoenix, Jekyll and Webpack.
Everything is fast, and the development loop isn't riddled with weird bugs or edge cases. I didn't come across any issues.
Besides those apps things like SSH, GPG keys and various other Linux tools are working great.
How about node? Is it really fast? Few months ago,when I tried WSL, npm install in a fresh laravel scaffolding took atleast 10 minutes. Disk performance was very very poor.
Since then, I left WSL. Is it really fast? When comparted to dual booted Linux?
Node is listed there as well as Webpack.
I use Webpack in nearly all of my web apps and in a typical Webpack set up using ES6 JS + PostCSS + SCSS + Bootstrap + Font Awesome 5 + custom SCSS, it's really fast. Webpack takes around 500-600ms to pickup the changes if I make a SCSS change and JS is even less time.
It updates faster than I can move my cursor to my browser and hit CTRL + R to reload.
Laravel is another story. The initial composer install takes a while, a lot longer than Rails or any of the other set ups, but... once everything is installed, the disk performance is fine. If I make a change to an asset, it picks it up in less than 1 second and code changes to the Laravel app itself is nearly instant.
But to be fair, I don't work with Laravel on a regular basis. 99% of my client work is one of the tools listed in my other reply. It just so happens I was working with a Laravel app yesterday tho, so this is still fresh in my mind.
Dual booting isn't an option for me. I used to do it, and it's a horrible context switch, even if it only takes a minute with an SSD. It's the fact that you lose everything between each dual boot.
Plus for me, it's not an option because I need to be able to record my development environment with video editing tools and nothing exists on Linux that's usable IMO.
Convincing enough about performance.
How about tooling support ? VSCode can provide linting via eslint and tslint packages. It can provide Autocomplete for Php using PHP interpreter. For such functionalities, VSCode requires PHP Interpreter. In case of WSL, everything lies in side it. VSCode installed to windows can't access the linux tooling inside WSL?
You have a few choices with tooling support.
For example I have VSCode running on Windows, but I have the shellcheck (Bash) linter installed directly in WSL and it works great because shellcheck has an option to make it work in WSL, so it really comes down to what tools you use.
But, if you want a sure fire way to get full support for everything, you can go down the route of installing VSCode directly inside of WSL instead of Windows.
That is mentioned in one of the blog posts I linked at nickjanetakis.com/blog/using-wsl-a.... Do a search for "Setting Up MobaXterm to Run Graphical Linux Apps".
WSL supports interoperability. I'm using it successfully with Sublimetext Sublimelinter and Vscode linters. Just check it out docs.microsoft.com/en-us/windows/w...
All my issues were with Node and packages dependencies.
I would not call anything Windows related fast.
Maybe it was an older version of WSL that you were using. Yarn install is pretty speedy for me with Windows 18.09's WSL.
You might want to try disabling Windows Defender for WSL or even all together. I know a lot of people said WSL was slow for them when you run that tool. It was one of the first things I disabled after installing Windows before I even used WSL.
Nice video! Does the
integration with Windows vscode ships out of the box?
Hey @nickjj , it's me again.
I've been playing around with WSL and I'm very impressed about the work done there. Talking about these integration between with the Windows host and the VSCode integration, I know there are some binaries as jdk's "java" binary which can be shared from the windows installation to WSL which I find very interesting because I can use java dependent windows programs and use command line tools (mvn, openapi-tools... etc) using the same jdk installation.
In the case of node & npm, do you recommend having a single shared installation or to installit in both Windows & WSL? The idea of having it avaialble in Windows is to have the option to run node dependent apps like Hyper or NativeScript Sidekick.
Hi,
I personally don't have Node installed on Windows, but it's up to you. I got rid of Hyper a while back because it was horrendously slow compared to other terminals. That adventure was documented at nickjanetakis.com/blog/conemu-vs-h....
But, I'm not here to rain on any parades. If you have some Node apps on Windows that benefit from having Node natively installed on Windows, then go for it.
Although with that said, I have VSCode installed on Windows but I didn't specifically install Node. I let VSCode manage its own installation.
I have dived into this setup and found an interesting behavior (a problem actually). Just opened a stackoverflow question to see if someone has done a similar setup. I have found a solution (workaround as of now, want to have other's opinion) but I'm posting it later, need some sleep.
I've never done anything like that but in your symlinks you have
node.exein the Windows path but then you putnpmandnpx. Shouldn't those also end with.exe?Yep. I didn't add anything special.
I only added an alias for
alias code="code-insiders"because I use Code Insiders but prefer typingcodeinstead ofcode-insiders.All of my Bash aliases and everything else (including VSCode config) is at github.com/nickjj/dotfiles.
Great! Another thing I would to know is.. How did you set your desktop theme (taskbar, apps toolbar... etc) to that nice looking blue? I have been in Linux for a while so I'm not aware of Windows customization... Perhaps I'm switching to a setup similar than yours :)
The theme colors are standard Windows 10 features.
Personalizemenu itemColorstab on the leftNow your taskbar, start menu and all of your windows will use that custom color.
If you're happy with your set up, you can goto the
Themestab on the left and then save it as a pre-set.I also modified VSCode's workbench colors so it matches my Windows theme. Those settings are in my dotfiles.
Hello Nick. Nice setup. I use a similar setup @ work these days as well. WSL indeed has come a long way in the past couple of years. For video editing are you using Adobe Creative Cloud? I ask 'cause CC + OSX might be an alternative if you find yourself running up against the limitations of WSL.
Either way, nice video. I look forward to the next one.
I use Camtasia for video recording and editing, or OBS for streaming.
I don't want to switch to MacOS because IMO there's better gaming support with Windows and I like the idea of having 1 computer that I use for both work and gaming.
There's other neat bonuses of WSL too for development over MacOS, such as having a "real'ish" Linux environment. I deploy all of my apps onto Ubuntu 18.04 using Ansible, and that means I can reuse a lot of things to set up my WSL environment since I also run Ubuntu 18.04 in WSL.
I've gotten things set up now where I can run 1 Ansible command and everything about my WSL set up gets automatically configured and it only took about 10 lines of YAML since I was able to reuse everything I use for my production environment in terms of Ansible code.
Could you go more in-depth on integrating Docker into the workflow? From what I understand, from looking at other tutorials, you need a 'volumes' section in the docker-compose file that looks at your code, with separate folders that aren't watched for dependencies, such as node-modules, venv if you're using that, etc?
For development I almost always volume mount
.:/appwhich would mount in the current directory (the source code) into the/apppath in the container which is a general place I use to keep my source code in the container, but in your case the/apppart might vary.I don't worry about
node_modules/because at Docker build time I configure yarn to install its dependencies into/node_modulesinside the Docker image instead ofnode_modules/which is relative to/app.You can do that with a
.yarnrcfile by putting in--modules-folder /node_modules.In other words, I don't end up with 42 billion node dependencies on my dev box through the volume because they're never mounted.
The same strategy applies with other language package managers that install dependencies to relative folders by default (such as Composer with PHP and Mix with Elixir).
Here is awesome podcast on how WSL works. As I understand there is no Linux kernel here.
hanselminutes.com/646/inside-linux...
irc <3
Thank you so much for sharing this...