About the Golang filepath fix on wasm

[Zxilly]

Recently I was working on my own project go-size-analyzer which contains a wasm compilation target, so I started checking for wasm related issues in the go compiler.

In this process, I noticed golang/go#43768 , an issue that also affects my application in some way. So I wrote a patch for it golang/go#68831.

It seems esbuild has been using go's wasm target for quite some time now, and I was wondering what your thoughts are on this fix? If this fix is merged, will it help esbuild development?

[evanw]

It would be wonderful if this bug in Go was finally fixed. However, I believe your fix would be irrelevant for esbuild as esbuild had to fork the entire Go file system library to avoid this bug, which was over three years ago now. Here's what esbuild does:

esbuild/internal/fs/iswin_wasm.go

Lines 17 to 21 in 9c13ae1

	// Hack: Assume that we're on Windows if we're running WebAssembly and
	// the "C:\\" directory exists. This is a workaround for a bug in Go's
	// WebAssembly support: https://github.com/golang/go/issues/43768.
	_, err := os.Stat("C:\\")
	cachedIfWindows = err == nil

esbuild/internal/fs/fs_real.go

Lines 67 to 73 in 9c13ae1

	if CheckIfWindows() {
	fp.isWindows = true
	fp.pathSeparator = '\\'
	} else {
	fp.isWindows = false
	fp.pathSeparator = '/'
	}

[Zxilly]

My idea is that the user can write this logic in glue js and at the same time it will work fine by default.
The esbuild hack seems to work for the most part, but operations like os.Stat("C:\") may always return err if you consider running in a browser. Considering that we now have the FileSystem API, this could be unnecessarily annoying.

[evanw]

Closing as this question has been answered.