Add ESBUILD_BIN_PATH

[sushain97]

Installation already appears to support a couple modes:

• ESBUILD_BIN_PATH_FOR_TESTS which symlinks an esbuild binary into node_modules
• installBinaryFromPackage which either installs from a local cache or downloads the binary from npm (directly or via npm)

However, this doesn't match our needs exactly. In particular, we run yarn install in --offline mode inside a micro VM without network access. Thus, we need a way to tell the esbuild installer about a binary that we've already downloaded. Since we need the node_modules to be standalone, ESBUILD_BIN_PATH_FOR_TESTS doesn't work since it creates a symlink.

We handle a similar issue with node-sass by using npm_config_sass_binary_cache. However, the local caching logic in esbuild is a little more involved and I'm loathe to attempt replicating it our end (especially since we support both darwin and linux -- see the hack mentioned later).

So, there are two potential solutions:

• Support ESBUILD_CACHE_PATH which overrides the cache directly
• Support ESBUILD_BIN_PATH which acts just like ESBUILD_BIN_PATH_FOR_TESTS but copies the file instead

I decided on the latter since that resolves the problem directly (although I do need to test this change with our build system... opening the PR early to see if there's any appetite for this tweak).

For completeness, my current hack is:

mkdir -p ~/.cache/esbuild/bin/
cp external/esbuild/bin/esbuild ~/.cache/esbuild/bin/[email protected]

(within the yarn install Bazel action)

[evanw]

I'm open to doing something like this but I'd like to reserve the right to break hacks like this this in the future. This is a super specific request and the implementation details of the installer isn't something I intended to be part of esbuild's public API. For example, in the future the installer may be changed to an entirely different approach such as #789, at which point anything relying on this will break.

[sushain97]

That's fair! I'm sure we can adjust our wrappers accordingly if it breaks.

While this use case is certainly rare, it's definitely something which folks have invested in: https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/. The current installation setup doesn't allow for offline installs unless you guess the cache path.

My skimming of #789 suggests that if esbuild switched to an approach where the package manager itself downloads the deps, the downloads would be no different from any other npm module and everything would Just Work.

[evanw]

FYI I'm going to change ESBUILD_BIN_PATH to ESBUILD_BINARY_PATH since that is already supported for overriding the binary path of the JavaScript API code at run-time (see #597).

[sushain97]

FYI I'm going to change ESBUILD_BIN_PATH to ESBUILD_BINARY_PATH since that is already supported for overriding the binary path of the JavaScript API code at run-time (see #597).

👍 Thanks for merging!