v0.15.9
-
Fix an obscure npm package installation issue with
--omit=optional
(#2558)The previous release introduced a regression with
npm install esbuild --omit=optional
where the filenode_modules/.bin/esbuild
would no longer be present after installation. That could cause any package scripts which used theesbuild
command to no longer work. This release fixes the regression sonode_modules/.bin/esbuild
should now be present again after installation. This regression only affected people installing esbuild usingnpm
with either the--omit=optional
or--no-optional
flag, which is a somewhat unusual situation.More details:
The reason for this regression is due to some obscure npm implementation details. Since the Go compiler doesn't support trivial cross-compiling on certain Android platforms, esbuild's installer installs a WebAssembly shim on those platforms instead. In the previous release I attempted to simplify esbuild's WebAssembly shims to depend on the
esbuild-wasm
package instead of including another whole copy of the WebAssembly binary (to make publishing faster and to save on file system space after installation). However, both theesbuild
package and theesbuild-wasm
package provide a binary calledesbuild
and it turns out that addingesbuild-wasm
as a nested dependency of theesbuild
package (specificallyesbuild
optionally depends on@esbuild/android-arm
which depends onesbuild-wasm
) caused npm to be confused about whatnode_modules/.bin/esbuild
is supposed to be.It's pretty strange and unexpected that disabling the installation of optional dependencies altogether would suddenly cause an optional dependency's dependency to conflict with the top-level package. What happens under the hood is that if
--omit=optional
is present, npm attempts to uninstall theesbuild-wasm
nested dependency at the end ofnpm install
(even though theesbuild-wasm
package was never installed due to--omit=optional
). This uninstallation causesnode_modules/.bin/esbuild
to be deleted.After doing a full investigation, I discovered that npm's handling of the
.bin
directory is deliberately very brittle. When multiple packages in the dependency tree put something in.bin
with the same name, the end result is non-deterministic/random. What you get in.bin
might be from one package, from the other package, or might be missing entirely. The workaround suggested by npm is to just avoid having two packages that put something in.bin
with the same name. So this was fixed by making the@esbuild/android-arm
andesbuild-android-64
packages each include another whole copy of the WebAssembly binary, which works because these packages don't put anything in.bin
.