Angular CLI as WSL 2.0 Test Case

I’ve been fascinated by the existence of Windows Subsystem for Linux (WSL) ever since its introduction. I’ve played with it occasionally, such as trying to run ROS on it. And this time I thought I’d try installing the Angular CLI on a WSL instance. But this time with a twist: this is now WSL 2.0, a big revamp of the concept. Architecturally, there’s now much more of an actual Linux distribution running inside the environment, which promises even better Linux compatibility and performance in Linux-native scenarios. The tradeoff is a reduction in performance of Windows-Linux interoperations, but apparently the team decided it was worthwhile.

But first, I have to run through the installation instructions which, on my 2004 build, encountered the error that required a Linux kernel update.

WSL 2 requires an update to its kernel component. For information please visit

Then I can install it from Microsoft store followed by an installation of Ubuntu. Then I installed Node.JS for Ubuntu followed by Angular CLI tools. The last step ran into the same permissions issue I saw on MacOS X with node-modules ownership. Once I took ownership, I got an entirely new error:

Error: EACCES: permission denied, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

The only resolution I found for this was “Run as root”. Unsatisfying, and I would be very hesitant if this was a full machine but I’m willing to tolerate it for a small virtual machine.

Once I installed Angular CLI, I cloned by “Tour of Heroes” tutorial repository into this WSL instance and tried ng serve. This triggered the error:

Cannot find module '@angular-devkit/build-angular/package.json'

Which turned out to be a Node.JS beginner mistake. Looking up the error I found this StackOverflow thread where I learned that cloning the repository was not enough. I also need to run “npm install” in that directory to set up Node dependencies.

Once those issues were resolved, I was able to run the application where I found two oddities. (1) I somehow didn’t completely remove the mock HEROES reference on my Mac? And (2) package.json and package-lock.json had lots of changes I did not understand.

But neither of those issues were as important as my hopes for more transparent networking support in WSL 2. Networking code running in WSL was not visible from elsewhere in my local network unless I jumped through some hoops with Windows Firewall, which was what made ROS largely uninteresting earlier for multi-node robots. WSL 2 claimed to have better networking support, but alas my Angular application’s “ng serve” was similarly unreachable from another computer on my local network.

Even though this test was a failure, judging by the evolution of WSL to WSL2 I’m hopeful that work will continue to make this more seamless in the future. At the very least I hope I wouldn’t have to use the “run as root” last resort.

Until the next experiment!

Windows Subsystem Returns for Linux

One of the newest features in Windows 10 is the “Windows Subsystem for Linux” (WSL) allowing a limited set of Linux binaries to run on the latest 64-bit edition of Windows 10. It may be a sign of open-source friendliness by the new Microsoft CEO but for trivia’s sake: it is not a new concept.

The lineage for Windows 10 traces all the way back to Windows NT, built-in the early 1990s as a heavier-duty operating system (or according to some, “a real operating system”) to move upscale relative to the existing DOS-based Windows (“not a real operating system”). As consumer-level hardware grew more capable, the old DOS core was phased out and the NT kernel took over. Windows 2000 was the modest start, followed by the successful Windows XP.

But back when Windows NT launched, it was intended to capture the business, enterprise, and government markets with higher margins than the consumer market. At the time, one requirement to compete for government contracts was support for POSIX, a IEEE-defined subset of Unix. The software architects for Windows NT built a modular design that supported multiple subsystems. In addition to the home-grown Microsoft Win32 and the POSIX subsystem to meet government requirement, there is also a subsystem for IBM OS/2 to compete in enterprises that had invested in OS/2.

History showed those subsystem were barely, if anything, more than lip service. They were not used much and gradually faded away in later evolution of the NT lineage.

But now, the concept returns.

Microsoft has a healthy and profitable market in desktop software development with Windows, but is only a marginal player in the web + cloud world. The people writing code there are more likely to be using a Linux workstation or a Macintosh with its FreeBSD-based MacOS. In an attempt to make Windows more relevant to this world, they need to provide access to the already entrenched tools.

So just like before, Microsoft is building a Linux subsystem for business competitive reasons. But unlike the POSIX subsystem, they couldn’t get away with just lip service to satisfy a checklist. It will actually need to be useful to gain meaningful traction.

The method of installation is a little odd – the supported Linux distributions are listed on the Microsoft Windows app store. But once we get past this square peg jammed in a round hole, it works well enough.

WSL is not a virtual machine or even a container. The Linux executables were not recompiled for Windows, they’re the exact same binaries. And they’re not isolated – they run side by side with the rest of Windows and has access to the same file system.

Personally, I’m using WSL so I can use the same git source control commands that I’ve learned while working in Ubuntu. I know Github has a Windows GUI and associated command-line toolkit, but I expect running the Ubuntu git via WSL would work better with git outside of Github. (Bitbucket, Heroku, etc.)

This is a good start. I hope WSL has a real life ahead to help Windows play well with others, and not fade away like its predecessors.