From d91ff61331abae4c699c5d3e6451969522f14a4a Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Tue, 2 Jul 2024 11:02:38 +0000
Subject: [PATCH] chore(deps): Bump esbuild from 0.21.5 to 0.23.0 (#175)
Bumps [esbuild](https://github.com/evanw/esbuild) from 0.21.5 to 0.23.0.
Sourced from esbuild's
releases. This release deliberately contains backwards-incompatible
changes. To avoid automatically picking up releases like
this, you should either be pinning the exact version of
Revert the recent change to avoid bundling dependencies for node (#3819) This release reverts the recent change in version 0.22.0 that made
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 (#3818) 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
// Old output (with --jsx=preserve) // New output (with --jsx=preserve)Release notes
v0.23.0
esbuild
in your package.json
file
(recommended) or be using a version range syntax that only accepts patch
upgrades such as ^0.22.0
or ~0.22.0
. See npm's
documentation about semver for
more information.
--packages=external
the default behavior with
--platform=node
. The default is now back to
--packages=bundle
.--jsx=preserve
. Here is an example:// Original code
<Foo>
<Bar />
</Foo>
<Foo><Bar /></Foo>;
<Foo>
<Bar />
</Foo>;
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 (#1874, #2830, #2846, #2915, #3145, #3294, #3323, #3582, #3809, #3815)
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).
Drop support for older platforms (#3802)
This release drops support for the following operating systems:
... (truncated)
Sourced from esbuild's changelog.
0.23.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 yourpackage.json
file (recommended) or be using a version range syntax that only accepts patch upgrades such as^0.22.0
or~0.22.0
. See npm's documentation about semver for more information.
Revert the recent change to avoid bundling dependencies for node (#3819)
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 (#3818)
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
. Here is an example:// Original code <Foo> <Bar /> </Foo>
// Old output (with --jsx=preserve)
<Foo><Bar /></Foo>;// New output (with --jsx=preserve)
<Foo>
<Bar />
</Foo>;
0.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 yourpackage.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 (#1874, #2830, #2846, #2915, #3145, #3294, #3323, #3582, #3809, #3815)
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 viapaths
and/orbaseUrl
intsconfig.json
(which are applied first).Drop support for older platforms (#3802)
This release drops support for the following operating systems:
- Windows 7
- Windows 8
- Windows Server 2008
... (truncated)
9d50680
publish 0.23.0 to npmac7fd04
Revert "fix #1874:
node defaults to --packages=external
" (#3820)626ac2c
fix #3818:
preserve collapsed jsx whitespace7c2eb2e
hashbang syntax is part of es202380c6e6e
publish 0.22.0 to npm196dcad
fix #1874:
node defaults to --packages=external
3f57db8
release notes for #353991663db
Provide API to create a custom esbuild CLI with plugins (#3539)e01c0e0
also mention #3665
in release notes65711b3
release notes for #3674