evanw/esbuild v0.8.32

on GitHub

Calling stop() on the JavaScript API is now optional (#656)

The JavaScript implementation of esbuild's API now calls unref() internally so node will now exit even if the internal long-lived esbuild process is still running. You should no longer need to explicitly call stop() on the service returned by startService(), which simplifies service lifetime management. This feature was contributed by @SalvatorePreviti.

Fix bug in metafile path generation (#662)

Certain import path metadata in the JSON file generated by the --metafile setting could be incorrect in scenarios with code splitting active and multiple entry points in different subdirectories. The incorrect paths referred to cross-chunk imports of other generated code splitting chunks and were incorrectly relative to the subdirectory inside the output directory instead of relative to the output directory itself. This issue has been fixed.

Add kind to import paths in metafile JSON (#655)

The --metafile flag generates build metadata in JSON format describing the input and output files in the build. Previously import path objects only had a path property. With this release, they now also have a kind property that describes the way the file was imported. The value is a string that is equal to one of the following values:

For JavaScript files:

• import-statement
• require-call
• dynamic-import
• require-resolve

For CSS files:

• import-rule
• url-token

Add support for TypeScript 4.2 syntax

Most of the new features included in the TypeScript 4.2 beta announcement are type system features that don't apply to esbuild. But there's one upcoming feature that adds new syntax: abstract construct signatures. They look like this:

let Ctor: abstract new () => HasArea = Shape;

This new syntax can now be parsed by esbuild.

Add detail to errors and warnings (#654)

Errors and warnings returned by the JavaScript and Go APIs now have a detail property which contains the original error. This is relevant if a custom JavaScript exception is thrown or a custom Go error is returned from inside a plugin callback.

Disable code warnings inside node_modules directories even with plugins (#666)

Some of the warnings that esbuild generates exist to point out suspicious looking code that is likely a bug. An example is typeof x == 'null' since the typeof operator never generates the string null. Arguably these warnings belong in a linter instead of in esbuild since esbuild is a bundler, but I figured that some warnings about obviously broken code would still be helpful because many people don't run linters. It's part of my quest to improve software quality. And these warnings have caught real bugs in published code so they aren't meaningless. The warning must be considered very unlikely to be a false positive to be included.

A change was added in version 0.7.4 to exclude files inside node_modules directories from these warnings. Even if the warnings flag a real bug, the warning is frustrating as a user because it's mostly non-actionable. The only resolution other than turning off warnings is to file an issue with the package, since code in published packages is immutable.

However, since then the plugin API has been released and this behavior didn't apply if the import path was resolved by a plugin. It only applied if the import path was resolved by esbuild itself. That problem is fixed in this release. Now these warnings will be omitted from any file with node_modules in its path, even if the path originated from a plugin.

Remove the warning about self-assignment (#666)

This warning was added in version 0.8.11 and warns about self-assignment such as x = x. The rationale is that this is likely a copy/paste error. However, it triggers too often for cross-compiled TypeScript code so the false positive rate is too high. The warning has now been removed.

Disable constant folding for the ?: operator when not minifying (#657)

When minification is not enabled, the ?: operator will now no longer be simplified if the condition evaluates to true or false. This could result in slower builds in certain cases because esbuild may now scan more files unnecessarily during bundling. This change was made because of a user request.