v0.8.43
-
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 theXDG_CACHE_HOME
environment variable exists. This allows you to customize the cache directory on Linux. The specification that definesXDG_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:;
orvar(--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 beingundefined
. This is caused by the__esModule
marker being added after the call torequire()
for the first transformed re-export statement. The fix was to move the marker to before the first call torequire()
. 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 variableThis 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 (callednodePaths
in JS andNodePaths
in Go).