Thread by @wycats

I've been using Windows for a few years. I originally switched because I noticed that there were a lot of Windows users trying to program in JavaScript, but that the dominant perspective in OSS (at the time) was "nobody uses Windows so it doesn't matter".

This is still a perspective I encounter frequently, but it's less ubiquitous these days.

The original switch was difficult (like any other OS switch), but even back then, there were a lot of things I really liked about Windows.

I still use a Mac 8 hours a day at work (pairing with @chancancode), so I'm in touch with both perspectives as a developer.

These days, I really like Windows, but this thread is not about that.

As a Windows developer, most things work pretty well (with or without Windows Subsystem for Linux, which is exciting but not reliable; I try not to depend on it for day-to-day development).

There are two categories of bugs that account for nearly 100% of the frustrations I have trying to develop software on Windows.

1. almost every package.json that isn't trying to be portable has `scripts` that don't work on Windows (in powershell or cmd).

This is usually because they use `&&`, but there's a long tail of other stuff going on.

I try not to rely on git-bash, because it isn't fully equivalent to bash on OSX, and while it reduces problems, the ones that remain are still frequent and harder to track down.

WSL is a less leaky abstraction than git-bash, but it's not reliable enough.

(as an aside, assuming that WSL is the end of the story for Windows devtools effectively assumes that nobody will need to build Windows binaries anymore--it would be a catastrophic mistake for an ecosystem to abandon .net developers by migrating fully to WSL)

So first problem: people's npm scripts are hardcoded to bash.

My usual solution: add shelljs as a dependency, move my script into `scripts/` and invoke it from `scripts`.

Upside: you can actually write programs in a .js file! You can have functions!

npm could also improve things (similar to Ruby) by implementing the most common subset of bash (&&, ||, redirects) and documenting it well. I like this aspect of Ruby and think it could be a big boon for interop in the node ecosystem.

Second problem: people have convinced themselves that they don't need to worry about the difference between path separators on different operating systems.

Nearly 100% of bugs that I encounter on Windows developing node stuff comes from some package assuming that they can just assume `/` is the path separator.

Most recently, I lost hours tracking down code that assumed that a scoped npm package from the file system would be reported by yarn as `@glimmer/runtime`. Instead, it was reported by yarn as `@glimmer\\runtime`.

A regex was looking for `/` (to determine "scoped") and failed.

This is probably a bug in npm's json output, but it's a good example of the unintended consequences of just assuming `/` everywhere across the ecosystem.

The most common source of `/` bugs comes from a workaround for the max-file-path problem. For the longest time, paths on Windows have a size limit. The way to work around this is to use verbatim paths, which start with \\?\.

Those paths don't have size limitations, but require all characters to be specified verbatim--no special normalization (including `/` -> `\`) occurs.

This means that path concatenation (`${head}/${tail}`) fails if `head` is a verbatim path.

Again, verbatim paths exist in the wild all over the place by (correct) code trying to work around file size limitations, and if you're in an ecosystem using this (correct) mitigation, trivial path concatenation causes major bugs.

The solution to this problem is to use path.join() (or equivalent, like resolve) rather than concatenating strings. If you're going to split a string into parts, use normalize (turns `/` into `\\`, among other things) and then split over path.sep.

This could also be mitigated somewhat *in node* by turning long paths into verbatim paths in the implementation, which would reduce the need for the user-space verbatim workaround.

That mitigation would still fail if someone is using a verbatim path on purpose, but that world would be so much better than the current world that it's probably worth it.

(at this point, using a verbatim path would mean "I really want this to be interpreted verbatim", which would be the opt-in for paths that shouldn't be touched).

But at the moment, using `/` and string concatenation to concatenate paths is a portability hazard and you shouldn't do it.

So all in all, two major hazards:

- package.json scripts that rely on bashisms
- an ecosystem-wide assumption that `/` is the right path separator on Windows

If we fix those two bugs (in userspace or in node), things would get way better overnight.

(I meant yarn's json output)