Log message:
esbuild: update to 0.24.0

0.24.0
------

Fix class field decorators in TypeScript if useDefineForClassFields is false

Setting the useDefineForClassFields flag to false in tsconfig.json means class
fields use the legacy TypeScript behavior instead of the standard JavaScript
behavior. Specifically they use assign semantics instead of define semantics
(e.g. setters are triggered) and fields without an initializer are not
initialized at all. However, when this legacy behavior is combined with
standard JavaScript decorators, TypeScript switches to always initializing all
fields, even those without initializers. Previously esbuild incorrectly
continued to omit field initializers for this edge case. These field
initializers in this case should now be emitted starting with this release.

Avoid incorrect cycle warning with tsconfig.json multiple inheritance

TypeScript 5.0 introduced multiple inheritance for tsconfig.json files where
extends can be an array of file paths. Previously esbuild would incorrectly
treat files encountered more than once when processing separate subtrees of the
multiple inheritance hierarchy as an inheritance cycle. With this release,
tsconfig.json files containing this edge case should work correctly without
generating a warning.

Handle Yarn Plug'n'Play stack overflow with tsconfig.json

Previously a tsconfig.json file that extends another file in a package with an
exports map could cause a stack overflow when Yarn's Plug'n'Play resolution was
active. This edge case should work now starting with this release.

Work around more issues with Deno 1.31+

This version of Deno broke the stdin and stdout properties on command objects
for inherited streams, which matters when you run esbuild's Deno module as the
entry point (i.e. when import.meta.main is true). Previously esbuild would
crash in Deno 1.31+ if you ran esbuild like that. This should be fixed starting
with this release.

0.23.1
------
Allow using the node: import prefix with es* targets

The node: prefix on imports is an alternate way to import built-in node
modules. For example, import fs from "fs" can also be written import \ 
fs from
"node:fs". This only works with certain newer versions of node, so esbuild
removes it when you target older versions of node such as with --target=node14
so that your code still works. With the way esbuild's platform-specific feature
compatibility table works, this was added by saying that only newer versions of
node support this feature. However, that means that a target such as
--target=node18,es2022 removes the node: prefix because none of the es* targets
are known to support this feature. This release adds the support for the node:
flag to esbuild's internal compatibility table for es* to allow you to use
compound targets.

Fix a panic when using the CLI with invalid build flags if --analyze is present

Previously esbuild's CLI could crash if it was invoked with flags that aren't
valid for a "build" API call and the --analyze flag is present. This \ 
was caused
by esbuild's internals attempting to add a Go plugin (which is how --analyze is
implemented) to a null build object. The panic has been fixed in this release.

Fix incorrect location of certain error messages

This release fixes a regression that caused certain errors relating to variable
declarations to be reported at an incorrect location. The regression was
introduced in version 0.18.7 of esbuild.

Print comments before case clauses in switch statements

With this release, esbuild will attempt to print comments that come before case
clauses in switch statements. This is similar to what esbuild already does for
comments inside of certain types of expressions. Note that these types of
comments are not printed if minification is enabled (specifically whitespace
minification).

Fix a memory leak with pluginData

With this release, the build context's internal pluginData cache will now be
cleared when starting a new build. This should fix a leak of memory from
plugins that return pluginData objects from onResolve and/or onLoad callbacks.

0.23
----

Revert the recent change to avoid bundling dependencies for node

This release reverts the recent change in version 0.22.0 that made
--packages=external the default behavior with --platform=node. The default is
now back to --packages=bundle.

I've just been made aware that Amazon doesn't pin their dependencies in their
"AWS CDK" product, which means that whenever esbuild publishes a new \ 
release,
many people (potentially everyone?) using their SDK around the world instantly
starts using it without Amazon checking that it works first. This change in
version 0.22.0 happened to break their SDK. I'm amazed that things haven't
broken before this point. This revert attempts to avoid these problems for
Amazon's customers. Hopefully Amazon will pin their dependencies in the future.

In addition, this is probably a sign that esbuild is used widely enough that it
now needs to switch to a more complicated release model. I may have esbuild use
a beta channel model for further development.

Fix preserving collapsed JSX whitespace

When transformed, certain whitespace inside JSX elements is ignored completely
if it collapses to an empty string. However, the whitespace should only be
ignored if the JSX is being transformed, not if it's being preserved. This
release fixes a bug where esbuild was previously incorrectly ignoring collapsed
whitespace with --jsx=preserve.

Log message:
Revbump all Go packages after go122 update

Log message:
Revbump all Go packages after update

Log message:
Revbump all Go packages after go122 security update

Log message:
v0.22.0

This release deliberately contains backwards-incompatible changes. To avoid
automatically picking up releases like this, you should either be pinning the
exact version of esbuild in your package.json file (recommended) or be using a
version range syntax that only accepts patch upgrades such as ^0.21.0 or
~0.21.0. See npm's documentation about semver for more information.

  * Omit packages from bundles by default when targeting node

    This breaking change is an experiment. People are commonly confused when
    using esbuild to bundle code for node (i.e. for --platform=node) because
    some packages may not be intended for bundlers, and may use node-specific
    features that don't work with a bundler. Even though esbuild's "getting
    started" instructions say to use --packages=external to work around this
    problem, many people don't read the documentation and don't do this, and
    are then confused when it doesn't work. So arguably this is a bad default
    behavior for esbuild to have if people keep tripping over this.

    With this release, esbuild will now omit packages from the bundle by
    default when the platform is node (i.e. the previous behavior of --packages
    =external is now the default in this case). Note that your dependencies
    must now be present on the file system when your bundle is run. If you
    don't want this behavior, you can do --packages=bundle to allow packages to
    be included in the bundle (i.e. the previous default behavior). Note that
    --packages=bundle doesn't mean all packages are bundled, just that packages
    are allowed to be bundled. You can still exclude individual packages from
    the bundle using --external: even when --packages=bundle is present.

    The --packages= setting considers all import paths that "look \ 
like" package
    imports in the original source code to be package imports. Specifically
    import paths that don't start with a path segment of / or . or .. are
    considered to be package imports. The only two exceptions to this rule are
    subpath imports (which start with a # character) and TypeScript path
    remappings via paths and/or baseUrl in tsconfig.json (which are applied
    first).

  * Update await using behavior to match TypeScript

    TypeScript 5.5 subtly changes the way await using behaves. This release
    updates esbuild to match these changes in TypeScript. You can read more
    about these changes in microsoft/TypeScript#58624.

  * Allow es2024 as a target environment

    The ECMAScript 2024 specification was just approved, so it has been added
    to esbuild as a possible compilation target. You can read more about the
    features that it adds here: https://2ality.com/2024/06/ecmascript-2024.html
    . The only addition that's relevant for esbuild is the regular expression /
    v flag. With --target=es2024, regular expressions that use the /v flag will
    now be passed through untransformed instead of being transformed into a
    call to new RegExp.

  * Publish binaries for WASI (WebAssembly System Interface) preview 1

    The upcoming WASI (WebAssembly System Interface) standard is going to be a
    way to run WebAssembly outside of a JavaScript host environment. In this
    scenario you only need a .wasm file without any supporting JavaScript code.
    Instead of JavaScript providing the APIs for the host environment, the WASI
    standard specifies a "system interface" that WebAssembly code can \ 
access
    directly (e.g. for file system access).

    Development versions of the WASI specification are being released using
    preview numbers. The people behind WASI are currently working on preview 2
    but the Go compiler has released support for preview 1, which from what I
    understand is now considered an unsupported legacy release. However, some
    people have requested that esbuild publish binary executables that support
    WASI preview 1 so they can experiment with them.

    This release publishes esbuild precompiled for WASI preview 1 to the
    @esbuild/wasi-preview1 package on npm (specifically the file @esbuild/
    wasi-preview1/esbuild.wasm). This binary executable has not been tested and
    won't be officially supported, as it's for an old preview release of a
    specification that has since moved in another direction. If it works for
    you, great! If not, then you'll likely have to wait for the ecosystem to
    evolve before using esbuild with WASI. For example, it sounds like perhaps
    WASI preview 1 doesn't include support for opening network sockets so
    esbuild's local development server is unlikely to work with WASI preview 1.

  * Warn about onResolve plugins not setting a path

    Plugins that return values from onResolve without resolving the path (i.e.
    without setting either path or external: true) will now cause a warning.
    This is because esbuild only uses return values from onResolve if it
    successfully resolves the path, and it's not good for invalid input to be
    silently ignored.

  * Add a new Go API for running the CLI with plugins

    With esbuild's Go API, you can now call cli.RunWithPlugins(args, plugins)
    to pass an array of esbuild plugins to be used during the build process.
    This allows you to create a CLI that behaves similarly to esbuild's CLI but
    with additional Go plugins enabled.

Log message:
Revbump all Go packages after go122 update

Log message:
Revbump all Go packages, default Go version is now 1.22.

Log message:
Revbump all Go packages after go121 update