In my blog post about deploying a Hugo site to Firebase hosting, I mentioned the inconvenience of jumping out of Visual Studio Code to use the Firebase CLI for project creation, maintenance and deployment. I’ve finally resolved this issue so that my workflow can now be kept 100% inside VS Code.

My current workflow

Here’s my current workflow on a Windows machine. I author my blog (via markdown and javascript/html files) in VS Code, then use Hugo to stage to localhost and generate static files for the site. Finally, I use the Google Firebase CLI to deploy to a Firebase-hosted website.

If you properly set your PATH environment variable correctly after installation, Hugo commands work fine inside VS Code via the Powershell terminal. However, I initially installed Firebase CLI as a standalone Windows package, which unlike the npm install, does not provide a global installation switch. As such, the Firebase command cannot be executed outside its dedicated CLI. I’ve tried adding it to the PATH environment variable, and also reinstalled it via node/npm, but have encountered various package dependency and conflict issues.

How to create a more seamless workflow

I fixed this issue by doing these

  • enabling the Windows Linux Subsystem (version 2)
  • installing a proper Linux distribution
  • moving the tool chain (Hugo and Firebase) to the Linux subsystem.

WLS supports a wide variety of Linux distributions including Ubuntu, SUSE, Debian, etc., that you can install directly from the Microsoft Store. You can also build a package from your favorite distro and install it manually. In fact, you can install multiple distros to be used in WSL and switch among them per your need.

Here are the exact steps I’ve taken:

  1. Enable Windows Linux Subsystem by either installing it in Powershell or enabling it in the Windows Features - Turn Windows features on and off dialog box in Control Panel. wslcontrolpanel Using the PowerShell method will automatically enable the subsystem and install the Ubuntu distro, which you can change later. Using the latter method is more granular, giving you finer control on each of the step. In this example I’m demostrating the Control Panel method.

  2. Next you need to install a Linux distribution of your choice. You can easily do so by searching Linux distro in the Microsoft store.

    I picked Alpine due to its extremely lean size (<100MB) and high reviews. alpine

  3. After installation, go to Start and find the Alpine Linux terminal in the installed program list. Click to open it.

  4. Configure a new account and password as required.

  5. Alpine doesn’t come with sudo which is required in many tools’ install scripts. So our next step is to set that up and again, create new account/password as prompted. In subsequent steps we are using the apk package manager that comes with Alpine to manage all the installations.

    apk add sudo

  6. Install Hugo

    apk add hugo

  7. Install npm which is a prerequisite of Firebase

    apk add npm

  8. Do a global installation of Firebase CLI

    npm install -g firebase-tools

  9. In VS Code, open a new Terminal by either selecting Terminal/New Terminal in the menu, or click the + sign from the pull down list and choose [your Linux distro name] (WSL) terminal

  10. You can then use all the Hugo and Firebase commands as before.

Setting your Linux shell as default terminal

  1. In Visual Studio Code, press CTRL + SHIFT + P to open the Command Palette.
  2. Choose Terminal: Select Default Profile
  3. Select your preferred shell from there, in this case I picked Alpine (WSL).
  4. To launch the terminal, use the Ctrl+` keyboard shortcut with the backtick character.

Hugo Issues & Workaround

If your Hugo site folders reside in the Windows file system, which shows up as a file mount in WLS (e.g., as :/mnt/c/Hugo/Sites/YourSiteFolder# in the terminal prompt), you will encounter two issues,

  1. Hugo needs elevated priviledge to write static files (by default, to the public folder). To enable this, first run sudo -i or su - to elevate to root account. Then run the hugo command as usual.

  2. When you run hugo server to host the site on localhost, Live Reload (the Hugo feature that picks up any file update on-the-fly, rebuilds and redeploys) won’t work. This has been reported as an issue with WLS2.

Both issues can be worked around by moving the site folder to your Linux filesystem (e.g., under /home/YourUserName). If needed, you can also access it from Explorer via \\wsl$\[YourLinuxDistro]\home\YourUserName

This practice also aligns with the performance-based advice from Microsoft which states, we recommend against working across operating systems with your files, unless you have a specific reason for doing so. For the fastest performance speed, store your files in the WSL file system if you are working in a Linux command line (Ubuntu, OpenSUSE, etc). If you’re working in a Windows command line (PowerShell, Command Prompt), store your files in the Windows file system.

Conclusion

By taking the above steps, I was able to consolidate tool chains, simplify my workflow into a single IDE, and mimimize distraction.

I had previously used a dual-boot setup to run my Python environment in Ubuntu, and other productivity tools in Windows. Not only did I need to clone two copies of files (or access from cloud drive) to share common data, it was also a major distraction to logout and reboot just to switch the OS. The current setup is way more seamless and minimalized (in terms of # of tools/files to maintain).

The addition of a Linux distro also let me leverage powerful Linux utilities such as wget, curl, lynx, grep, etc. for my other development projects, not to mention the ability to consolidate Linux-first language tools such as Python in the same system. In fact, I just installed the Remote WSL extension for VS and will explore its functionalities in my future Python projects.