esbuild 0.8.43

v0.8.43

on Node.js NPM

Support the XDG_CACHE_HOME environment variable (#757)

On Linux, the install script for esbuild currently caches downloaded binary executables in ~/.cache/esbuild/bin. This change means esbuild will now try installing to $XDG_CACHE_HOME/esbuild/bin instead of the XDG_CACHE_HOME environment variable exists. This allows you to customize the cache directory on Linux. The specification that defines XDG_CACHE_HOME is here.

Further improve constant folding of branches (#765)

At a high level, this release adds the following substitutions to improve constant folding and dead code elimination:

• if (anything && falsyWithSideEffects) → if (anything, falsyWithSideEffects)
• if (anything || truthyWithSideEffects) → if (anything, truthyWithSideEffects)
• if (anything && truthyNoSideEffects) → if (anything)
• if (anything || falsyNoSideEffects) → if (anything)
• if (anything, truthyOrFalsy) → anything; if (truthyOrFalsy)

And also these substitutions for unused expressions:

• primitive == primitive → primitive, primitive
• typeof identifier → (remove entirely)

The actual substitutions are more complex since they are more comprehensive but they essentially result in this high-level behavior. Note that these substitutions are only done when minification is enabled.

Fix an edge case with CSS variable syntax (#760)

CSS variables are whitespace-sensitive even though other CSS syntax is mostly not whitespace sensitive. It is apparently common for this to cause problems with CSS tooling that pretty-prints and minifies CSS, including esbuild before this release. Some examples of issues with other tools include postcss/postcss#1404 and tailwindlabs/tailwindcss#2889. The issue affects code like this:

div {
  --some-var: ;
  some-decl: var(--some-var, );
}

It would be a change in semantics to minify this code to either --some-var:; or var(--some-var,) due to the whitespace significance of CSS variables, so such transformations are invalid. With this release, esbuild should now preserve whitespace in these two situations (CSS variable declarations and CSS variable references).

Add support for recursive symlinks during path resolution (#766)

Previously recursive symlinks (a symlink that points to another symlink) were an unhandled case in the path resolution algorithm. Now these cases should be supported up to a depth of 256 symlinks. This means esbuild's path resolution should now work with multi-level yarn link scenarios.

Fix subtle circular dependency issue (#758)

If esbuild is used to transform TypeScript to JavaScript without bundling (i.e. each file is transformed individually), the output format is CommonJS, and the original TypeScript code contains an import cycle where at least one of the links in the cycle is an export * as re-export statement, there could be certain situations where evaluating the transformed code results in an import being undefined. This is caused by the __esModule marker being added after the call to require() for the first transformed re-export statement. The fix was to move the marker to before the first call to require(). The __esModule marker is a convention from Babel that esbuild reuses which marks a module as being originally in the ECMAScript module format instead of the CommonJS module format.

Add support for the NODE_PATH environment variable

This is a rarely-used feature of Node's module resolution algorithm. From the documentation:

If the NODE_PATH environment variable is set to a colon-delimited list of absolute paths, then Node.js will search those paths for modules if they are not found elsewhere.

On Windows, NODE_PATH is delimited by semicolons (;) instead of colons.

The CLI takes the list of node paths from the value of the NODE_PATH environment variable, but the JS and Go APIs take the list as an array of strings instead (called nodePaths in JS and NodePaths in Go).