Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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.- Loading branch information
