npm go

You can download the go and go tool chain using npm by

npm install -g hxjiang-go-{OS}-{ARCH}

To differentiate between Go and npm installed Go, the installed Go binary is called hxjiang-go.

hongxiangjiang@MacBookPro hxjiang-go % which hxjiang-go
/Users/hongxiangjiang/.nvm/versions/node/v22.18.0/bin/hxjiang-go
hongxiangjiang@MacBookPro hxjiang-go % hxjiang-go env GOROOT
/Users/hongxiangjiang/.nvm/versions/node/v22.18.0/lib/node_modules/hxjiang-go-{OS}-{ARCH}/go

How it works?

package.json allow developers to add binaries (including pre-compiled binaries), when developer install a cerrtain package using npm install -g ${package}, all the binaries will be avaialble in node.js bin dir and all the package code will be available in lib subdir.

Why is the go smart enough to know the GOROOT?

If the go is not built from source, the go will try to figure out the GOROOT by following:

• GOROOT env var.
• ../..
• ../../..

After installing the go from npm, how did go figure out where is the GOROOT?

 ~/Desktop/codebase/ ls -l $(which hxjiang-go) 
lrwxr-xr-x  1 hxjiang  primarygroup  53 Aug  8 15:37 /Users/hxjiang/.nvm/versions/node/v20.18.0/bin/hxjiang-go -> ../lib/node_modules/hxjiang-go-darwin-arm64/go/bin/go

NPM create a symbolic in node bin dir (which is part of PATH) which pointing to the go command in the lib dir. So go command can follow ../.. to figure out GOROOT.

Why there is no tag in this git repo?

npm use the version information from the package.json. But I think it would be more clear if we have a tag in git repo as well.

TODO(hxjiang): is there a way to make it required to have both git tag and npm package version the same?

Having duplicate go toolchain for all OS x ARCH is not ideal. Having user downloading go follow npm package hxjiang-go-${OS}-${ARCH} is not ideal. what can we do to improve this.

I have done some research on this topic. The most promising result is, using optionalDependencies with folder / packages struture like this:

The parent level package is hxjiang-go and the go/bin/go and go/bin/gofmt are a wrapper which pointing to the actual implementation.

The actual go and gofmt binary is available as a dependency package of hxjiang-go.

hxjiang-go
|--- package.json
|--- go
|    |--- bin
|    |    |--- go (wrapper)
|    |    |--- gofmt (wrapper)
|    |--- api
|    |    ......
|    |--- pkg
|    |    ......
|--- hxjiang-go-darwin-arm64
|    |---go
|    |    |--- bin
|    |         |--- go 
|    |         |--- gofmt 
|--- hxjiang-go-darwin-amd64
|    |---go
|    |    |--- bin
|    |         |--- go 
|    |         |--- gofmt 
|--- hxjiang-go-linux-arm64
|    |---go
|    |    |--- bin
|    |         |--- go 
|    |         |--- gofmt 
|--- hxjiang-go-linux-arm64
|    |---go
|    |    |--- bin
|    |         |--- go 
|    |         |--- gofmt 
|--- hxjiang-go-OS-ARCH
.......

What is optional dependency and why?

optional dependency allow package developer to add dependencies to your package. The dependency package can specify OS and ARCH. When user install go using npm install -g hxjiang-go, npm dynamically figureout which OS and ARCH is available for user's workstation. So only one of the distribution will be installed.

However, the binary of the optional dependency is not added to the node module bin dir automatically. That's why the wrapper is needed.

The wrapper will automatically choose which go to run. Another solution is to have a post installation script which will replace the wrapper with the actual go. Like a mv hxjiang-go-OS-ARCH/go/bin/* go/bin/.

All these are community solution raised at esbuild.

However, this approach need more time to investigate how NPM works and how esbuild write their post installation script. But I believe this should be doable.