DEV Community: nirtamir2

How to configure oh-my-zsh on Windows

nirtamir2 — Sat, 03 Jul 2021 14:40:49 +0000

There are 2 major ways to install oh-my-zsh in Windows: With WSL / without WSL.

Installation with WSL

WSL (Windows Subsystem for Linux) is a Windows feature that lets developers run a GNU/Linux environment -- including most command-line tools, utilities, and applications -- directly on Windows, unmodified, without the overhead of a traditional virtual machine or dual-boot setup.

You can use the WSL2 which is faster than v1. After the installation - you can install Ubuntu (a Linux distribution) from the Windows app store. Just follow the official guide.

I tried it for a while. You get the benefit of full Linux distribution inside Windows.

Some things to notice

You have 2 file systems. The subsystem files can be accessed differently via local network drive / command line. It's less convenient for me to get those files from the Linux system - instead of one single system. The paths are different.
You use your windows apps and install some command line packages in the Linux side. Your code is stored in the Linux environment.
VSCode and Webstorm that are installed on your Windows can read/write your files from the Linux environment.
Every package you want to access with your Linux system's command line - should be installed on the Linux system. So this make you install tools like git, Node.js, Yarn and global packages on the Linux side too. If you want to develop sometimes on windows and sometimes on Linux - you will get some duplications.

Why I don't use WSL2 anymore

I tried to use WSL2 for a while, but then I notice a major problem: my dev server did not notice file changes. Tools like nodemon, hot-module-replacement and fast refresh did not work. It turns out that there is a open issue:

[WSL2] File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps #4739

SteveSandersonMS posted on Dec 06, 2019

WSL2 is really close to being a perfect runtime environment for server apps being developed in Windows. Great job! One missing feature however is breaking a core part of the developer flow.

For sources stored on the Windows filesystem, any changes made by Windows applications such as Visual Studio do not trigger any file change notifications as far as Linux apps are concerned. This means that all "live rebuild"-type tools don't work (examples: webpack --watch, jekyll --interactive, and Tilt.dev) when running under WSL2. This unfortunately renders many modern dev workflows unviable.

Notes:

I strongly expect this is already a known issue as hinted here. However I was unable to find any open GitHub issue that specifically tracks this. #1956 is about a different scenario, #4064 isn't specifically about change notifications, #4224 is closed, #4293 doesn't fix it.
I'm aware the WSL team suggests that with WSL2 it's good to store your application sources inside the Linux filesystem instead of the Windows one. However I don't think that's a viable solution since the whole point of WSL (for me) is to be able to use Windows-based editors such as full VS with a Linux dev environment. If it was sufficient to use Linux-based editors, I'd just use Mac/Linux as my actual OS and would have no need for WSL.
This did work great on WSL1
Changing fs.inotify.max_user_watches doesn't affect this, since the issue is about changes originating on the Windows side.

Bug report template

Your Windows build number: 10.0.19033.1
What you're doing and what's happening:

This applies to all tools that listen for file change notifications, but as an example take webpack. Repro steps:
- In your Windows filesystem, create an empty directory (example: c:\repro), and then add these three files to it
- In a WSL2 Ubuntu 18.04 environment, install Node and NPM: sudo apt-get install nodejs npm
- Still in WSL2, go into the directory from earlier: cd /mnt/c/repro
- Restore NPM dependencies: npm i
- Run Webpack in watch mode: npm run build:watch. Wait a few seconds until it completes the first build. It will now be waiting for further changes to your source files.
- In a Windows application (e.g., Notepad or Visual Studio), open c:\repro\index.js and save some change to it. For example, change 'Hello, world' to 'Hello, world 2'.
What's wrong / what should be happening instead:

Expected behavior: Webpack should see the change and rebuild. That is, you'll see it log information about another build, and the output in dist/bundle.js will be updated.

Actual behavior: Webpack doesn't respond at all, because there's no file change notification.

Finally I understand that the fix for this is likely to be "add file watch capabilities to the Plan9 server", and you may feel this is already being tracked by #4064. However #4064 describes a more obscure symptom of this missing feature and makes it sound like an intermittent issue. What I'm reporting here is not intermittent at all, and is a pretty mainstream scenario (using tools like webpack --watch). Thanks!

View on GitHub

Some of those problems have workaround with polling instead of file watching. I try the polling approach with vite, but the experience was poor compared to vite regular fast refresh. This was BLOCKER issue for me so I removed WSL2.

Installation without WSL2

Install Cygwin

Cygwin is a large collection of GNU and Open Source tools which provide functionality similar to a Linux distribution on Windows.

This part of the post is based on zinox9's excellent post

Download Cygwin from it's website and run the installer.
Make Sure to Let the installer install at C:\cygwin64
For Download site Select Any URL , Click Add
STOP at packages screen, search wget expand All under Web select latest version of it under bin of wget no need to select Source. Then Continue.
Finish Installing and launch the Terminal.
We are going to use Cygwin to Install Some Packages that will help to use Linux System on Windows. We will install apt-cyg which will work like apt-get and also install many other packages too like vim.
- Run The following to download apt-cyg with wget. Note you can prompt to install gdb, vim or dos2unix if you want to use them or just remove them, you can install even more packages of your choice if you wish !
```
wget rawgit.com/transcode-open/apt-cyg/master/apt-cyg
install apt-cyg /bin
apt-cyg install zsh git gdb dos2unix openssh chere vim
```

If you want your home folder to be your user's folder, you need to edit cygwin64/etc/nsswitch.conf. You can do this in the text editor you just downloaded, or type explorer /etc to open the root directory to edit the file. Add this line to the bottom: db_home: windows

Setting Up oh-my-zsh

Install oh-my-zsh from it's website or github.
Add plugins - I use 3 plugins for my dev environment:
- git (from oh-my-zsh plugins)
- zsh-yarn-completions
- zsh-autosuggestions

So my ~/.zshrc file looks like plugins=(git zsh-yarn-completions zsh-autosuggestions)

I also add alias for open to the windows explorer

alias open=explorer.exe

Integrate with terminals

Windows terminal

Edit your settings.json with the following profile:

    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44ba}",
    "profiles": 
    {
        "defaults": {},
        "list": 
        [
            {
                "background": "#282C34",
                "commandline": "C:/cygwin64/bin/bash.exe /bin/xhere /bin/zsh",
                "cursorColor": "#FFFFFF",
                "foreground": "#DCDFE4",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44ba}",
                "hidden": false,
                "name": "Work",
                "startingDirectory": "C://devl//work"
            },
      ]
  }

VSCode

In settings.json add the following settings:

"terminal.integrated.shell.windows": "C:\\Cygwin64\\bin\\bash.exe",
  "terminal.integrated.shellArgs.windows": ["/bin/xhere", "/bin/zsh"],

Webstorm

Add C:/cygwin64/bin/bash.exe /bin/xhere /bin/zsh to Shell path setting

Conclusion

I highly recommend using oh-my-zsh in your dev environment for better auto-completions in your terminal. Because of file watching issue with WSL2, I use Cygwin to help with the zsh installation.
If you know some improvements to this setup - feel free to comment about.

Using Vite with React

nirtamir2 — Mon, 10 May 2021 19:31:28 +0000

Background

It all started when I had to configure another simple thing in webpack (4.x). It's a SPA monorepo app written with React, TypeScript, and styled-components. It takes ~2 minutes to start the dev server for the UI. Which is kind of frustrating. The fast-refresh is also not that fast, and you can see a notable delay between updates.

Understanding that migration to managed SSR solutions like Next.js takes more time, effort, and a stiff learning curve for my team, I had an opportunity to integrate one of the new shiny bundle tools that use esbuild + ES modules (ESM) with almost not config. esbuild is "An extremely fast JavaScript bundler and minifier". EXTREMELY FAST:

Why it's so fast? because it's written in go and does a lot of optimizations.
ES modules is a new browser feature that enables to natively load modules - meaning no need to bundle everything in one giant bundle. We can split the code into smaller modules and load them as needed. This helps avoid unnecessary work and stay fast no matter how big the project grows.

I already played with those tools with some little demos at home for my learning. But now I had to find a way to use them in the production app in my company.

Snowpack vs Vite vs WMR

It did not take a lot of time to choose the tool. Currently, there are 3 major bundlers powered by ESM - vite, snowpack, and wmr. From the first glance - all of them look promising and I did not care about their internals as long as I don't need to touch them.

I chose Vite for 2 main reasons:

Vite handles monorepos better (snowpack work is still in progress).
wmr does not have error overlay / SVGR support

I think that soon - those issues will be resolved, but for now, I bet on vite.

For deeper comparison, you can look at this article from vite's documentation, but also notice that some of the latest snowpack progression does not mention there.

One of the benefits I like about those tools is that they require less configuration to write - they all support all the major workarounds out of the box. So you don't tie into complex configs like in webpack. You don't need to config anything to support TypeScript, React, Babel, manage public or static assets, fast-refresh, dynamic imports, etc... This makes migration easy if we will want.

The code you don't have to write - is the code that doesn't lift you from migration. It's not a major bet if you don't have to risk much.

The journey to configure vite

Looking at the example at vite-create-app ts-react template I was able to configure 80% of the work.

But I already know that it's one of those cases that those last 20% take more time to configure than the first 80%. Those tiny bugs / unmatched stuff you have to fix. Some of them are:

I had to fix some unrelated TypeScript type definitions. I don't know why do we have code like const f = <T,>() => return f2<T>() and why vite (or it may be a rollup / TypeScript issue?) struggles to transpile it - I convert this, for now, to <T extends unknown> which is equivalent to make it work.
We already have configured path aliases with webpack and tsconfig - so I wanted to keep that behavior. Luckily we have the vite-tsconfig-paths exactly for that. It worked well. I could also try using the alias for that.
Instead of webpack svgr - vite has a community plugin vite-plugin-svgr. Looking at its source code I can tell that it does the work as needed. In the future, I may want to add more SVGR options (currently for custom colors we use css currentColor property), so I may contribute it or create a similar plugin. NOTE: vite bundles the static svg in addition to assets even if you use vite-plugin-svgr. So many useless files will be generated. This is a minor issue that can be unnoticeable. I created a script for deleting those files (it has 0 impacts on the bundle because the client does not download those chunks).
Vite docs recommended specifying vite/client types in tsconfig.json. Before we did not explicitly specify this property - so we have to include other needed types like jest and node
```
{
  "compilerOptions": {
    "types": ["vite/client"]
  }
}
```

Issues with 3rd party libraries

Small issue with react-query devtools that solved by changing to a different minor version. But it's more an issue with the library.
react-markdown v4 also has an issue using process.cwd internally. I upgraded to v5 and the problem is gone. It seems that like in webpack 5 - you won't get and node.js polyfills with vite.

Now for the harder problems:

Some of our components depend on process.env.NODE_ENV. Our old webpack config uses define-plugin to replace them with their node.js env values. So I specify them with define:
```
define: {
  'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV)
}
```
Some third-party libraries like nivo for graphs use internally Node.js specific global keyword (here). But ES modules do not support it - and we get a Reference not found error for global variable. What vite tries to do is to convert them to be ESM - and run them in the browser. But the browser does not know what global is - so it fails. At first, I try to handle this in vite.config.ts with define - setting global: {} . But doing so created a problem with import GlobalStyles from "./global.style" then converted to be unwanted import GlobalStyles from "./{}.style" . So until nivo will upgrade to ES-modules - I hacked that global variable by pre-load in index.html like
```
<script>window.global = {}</script>
<script src="./src/index.tsx"/>
```

Env variables

The next thing I had to handle is the env variables. vite put the env variables inside import.meta.env (did you know import.meta is in the spec + node.js compatible?). Like next.js - if you want to expose them to the client-side you can use the VITE_APP_YOUR_VARIABLE_NAME - which is nice. For TypeScript users - vite docs encourage to add to tsconfig.json's compilerOptions with types:["vite/client"] . But explicit writing types entry - you lose your jest, testing-library and node typings library supports. So you have to manually specify them too. You can now get vite typings - but they are still missing your env variables types. You can declare them like here.

I wonder it's better to just use dotenv + env variables that like I did with define?

It makes stuff simplified.

Jest

I had a problem with our tests with the ts-jest preset that did not understand what import.meta is. So I kept using process.env in our code instead of import.meta. This may not be a concern for you because it looks like vite is planning to create its own jest preset to solve this problem.

Bundle analyze

In our "old" build system - I configured webpack-bundle-analyze to inspect bundle chunks and understand what it made of. I added rollup-bundle-visualyzer instead (although there is an issue that the reported size is not correct).

The final `vite.config.ts`

import reactRefresh from "@vitejs/plugin-react-refresh";
import bundleVisualizer from "rollup-plugin-visualizer";
import { defineConfig } from "vite";
import svgr from "vite-plugin-svgr";
import tsconfigPaths from "vite-tsconfig-paths";

function getBundleVisualizerPlugin() {
    return {
        ...bundleVisualizer({
            template: "treemap", // or sunburst
            open: true,
            gzipSize: true,
            brotliSize: true,
        }),
        apply: "build",
        enforce: "post",
    } as Plugin;
};

// https://vitejs.dev/config/
export default defineConfig({
    plugins: [
        reactRefresh(),
        svgr(),
        tsconfigPaths(),
        process.env.BUNDLE_ANALYZE === "1" && getBundleVisualizerPlugin(),
    ].filter(Boolean),
    define: {
        "process.env.NODE_ENV": JSON.stringify(process.env.NODE_ENV),
    },
});

I will change the as Plugin type assertion when my PR to @types/rollup-bundle-visualyzer will be merged

Summary

All the struggle to configure vite since the moment I decided until my PR merged took one day. Now we have a fast development environment for improved productivity. I'm sure that not all 3rd party libraries are compatible with vite. But things are getting better. The tech world evolves and I hope that library authors will eventually supply maintain ESM compatible build.

My conclusion is that if you won't need SSR (which experimentally supported in vite), I encourage you to try vite / other ESM build tools. It will make your dev environment really fast. Start with the docs, Skim https://github.com/vitejs/awesome-vite and look at the open issues too. It will make your dev environment really fast.