-
Notifications
You must be signed in to change notification settings - Fork 16
Commit 35b07ab
authored
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?v=4&size=40){kind=avatar}
chore(deps): update dependency esbuild to v0.25.0 (#1772)
This PR contains the following updates:
| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [esbuild](https://redirect.github.com/evanw/esbuild) | [`^0.15.10` ->
`^0.25.0`](https://renovatebot.com/diffs/npm/esbuild/0.15.10/0.25.0) |
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
| [esbuild](https://redirect.github.com/evanw/esbuild) | [`0.24.2` ->
`0.25.0`](https://renovatebot.com/diffs/npm/esbuild/0.24.2/0.25.0) |
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
---
### Release Notes
<details>
<summary>evanw/esbuild (esbuild)</summary>
###
[`v0.25.0`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#v0250)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.24.2...v0.25.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.24.0` or `~0.24.0`. See npm's documentation about
[semver](https://docs.npmjs.com/cli/v6/using-npm/semver/) for more
information.
- Restrict access to esbuild's development server
([GHSA-67mh-4wv8-2f99](https://redirect.github.com/evanw/esbuild/security/advisories/GHSA-67mh-4wv8-2f99))
This change addresses esbuild's first security vulnerability report.
Previously esbuild set the `Access-Control-Allow-Origin` header to `*`
to allow esbuild's development server to be flexible in how it's used
for development. However, this allows the websites you visit to make
HTTP requests to esbuild's local development server, which gives
read-only access to your source code if the website were to fetch your
source code's specific URL. You can read more information in [the
report](https://redirect.github.com/evanw/esbuild/security/advisories/GHSA-67mh-4wv8-2f99).
Starting with this release,
[CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) will now
be disabled, and requests will now be denied if the host does not match
the one provided to `--serve=`. The default host is `0.0.0.0`, which
refers to all of the IP addresses that represent the local machine (e.g.
both `127.0.0.1` and `192.168.0.1`). If you want to customize anything
about esbuild's development server, you can [put a proxy in front of
esbuild](https://esbuild.github.io/api/#serve-proxy) and modify the
incoming and/or outgoing requests.
In addition, the `serve()` API call has been changed to return an array
of `hosts` instead of a single `host` string. This makes it possible to
determine all of the hosts that esbuild's development server will
accept.
Thanks to [@​sapphi-red](https://redirect.github.com/sapphi-red)
for reporting this issue.
- Delete output files when a build fails in watch mode
([#​3643](https://redirect.github.com/evanw/esbuild/issues/3643))
It has been requested for esbuild to delete files when a build fails in
watch mode. Previously esbuild left the old files in place, which could
cause people to not immediately realize that the most recent build
failed. With this release, esbuild will now delete all output files if a
rebuild fails. Fixing the build error and triggering another rebuild
will restore all output files again.
- Fix correctness issues with the CSS nesting transform
([#​3620](https://redirect.github.com/evanw/esbuild/issues/3620),
[#​3877](https://redirect.github.com/evanw/esbuild/issues/3877),
[#​3933](https://redirect.github.com/evanw/esbuild/issues/3933),
[#​3997](https://redirect.github.com/evanw/esbuild/issues/3997),
[#​4005](https://redirect.github.com/evanw/esbuild/issues/4005),
[#​4037](https://redirect.github.com/evanw/esbuild/pull/4037),
[#​4038](https://redirect.github.com/evanw/esbuild/pull/4038))
This release fixes the following problems:
- Naive expansion of CSS nesting can result in an exponential blow-up of
generated CSS if each nesting level has multiple selectors. Previously
esbuild sometimes collapsed individual nesting levels using `:is()` to
limit expansion. However, this collapsing wasn't correct in some cases,
so it has been removed to fix correctness issues.
```css
/* Original code */
.parent {
> .a,
> .b1 > .b2 {
color: red;
}
}
/* Old output (with --supported:nesting=false) */
.parent > :is(.a, .b1 > .b2) {
color: red;
}
/* New output (with --supported:nesting=false) */
.parent > .a,
.parent > .b1 > .b2 {
color: red;
}
```
Thanks to [@​tim-we](https://redirect.github.com/tim-we) for
working on a fix.
- The `&` CSS nesting selector can be repeated multiple times to
increase CSS specificity. Previously esbuild ignored this possibility
and incorrectly considered `&&` to have the same specificity as `&`.
With this release, this should now work correctly:
```css
/* Original code (color should be red) */
div {
&& { color: red }
& { color: blue }
}
/* Old output (with --supported:nesting=false) */
div {
color: red;
}
div {
color: blue;
}
/* New output (with --supported:nesting=false) */
div:is(div) {
color: red;
}
div {
color: blue;
}
```
Thanks to [@​CPunisher](https://redirect.github.com/CPunisher) for
working on a fix.
- Previously transforming nested CSS incorrectly removed leading
combinators from within pseudoclass selectors such as `:where()`. This
edge case has been fixed and how has test coverage.
```css
/* Original code */
a b:has(> span) {
a & {
color: green;
}
}
/* Old output (with --supported:nesting=false) */
a :is(a b:has(span)) {
color: green;
}
/* New output (with --supported:nesting=false) */
a :is(a b:has(> span)) {
color: green;
}
```
This fix was contributed by
[@​NoremacNergfol](https://redirect.github.com/NoremacNergfol).
- The CSS minifier contains logic to remove the `&` selector when it can
be implied, which happens when there is only one and it's the leading
token. However, this logic was incorrectly also applied to selector
lists inside of pseudo-class selectors such as `:where()`. With this
release, the minifier will now avoid applying this logic in this edge
case:
```css
/* Original code */
.a {
& .b { color: red }
:where(& .b) { color: blue }
}
/* Old output (with --minify) */
.a{.b{color:red}:where(.b){color:#​00f}}
/* New output (with --minify) */
.a{.b{color:red}:where(& .b){color:#​00f}}
```
- Fix some correctness issues with source maps
([#​1745](https://redirect.github.com/evanw/esbuild/issues/1745),
[#​3183](https://redirect.github.com/evanw/esbuild/issues/3183),
[#​3613](https://redirect.github.com/evanw/esbuild/issues/3613),
[#​3982](https://redirect.github.com/evanw/esbuild/issues/3982))
Previously esbuild incorrectly treated source map path references as
file paths instead of as URLs. With this release, esbuild will now treat
source map path references as URLs. This fixes the following problems
with source maps:
- File names in `sourceMappingURL` that contained a space previously did
not encode the space as `%20`, which resulted in JavaScript tools
(including esbuild) failing to read that path back in when consuming the
generated output file. This should now be fixed.
- Absolute URLs in `sourceMappingURL` that use the `file://` scheme
previously attempted to read from a folder called `file:`. These URLs
should now be recognized and parsed correctly.
- Entries in the `sources` array in the source map are now treated as
URLs instead of file paths. The correct behavior for this is much more
clear now that source maps has a [formal
specification](https://tc39.es/ecma426/). Many thanks to those who
worked on the specification.
- Fix incorrect package for `@esbuild/netbsd-arm64`
([#​4018](https://redirect.github.com/evanw/esbuild/issues/4018))
Due to a copy+paste typo, the binary published to
`@esbuild/netbsd-arm64` was not actually for `arm64`, and didn't run in
that environment. This release should fix running esbuild in that
environment (NetBSD on 64-bit ARM). Sorry about the mistake.
- Fix a minification bug with bitwise operators and bigints
([#​4065](https://redirect.github.com/evanw/esbuild/issues/4065))
This change removes an incorrect assumption in esbuild that all bitwise
operators result in a numeric integer. That assumption was correct up
until the introduction of bigints in ES2020, but is no longer correct
because almost all bitwise operators now operate on both numbers and
bigints. Here's an example of the incorrect minification:
```js
// Original code
if ((a & b) !== 0) found = true
// Old output (with --minify)
a&b&&(found=!0);
// New output (with --minify)
(a&b)!==0&&(found=!0);
```
- Fix esbuild incorrectly rejecting valid TypeScript edge case
([#​4027](https://redirect.github.com/evanw/esbuild/issues/4027))
The following TypeScript code is valid:
```ts
export function open(async?: boolean): void {
console.log(async as boolean)
}
```
Before this version, esbuild would fail to parse this with a syntax
error as it expected the token sequence `async as ...` to be the start
of an async arrow function expression `async as => ...`. This edge case
should be parsed correctly by esbuild starting with this release.
- Transform BigInt values into constructor calls when unsupported
([#​4049](https://redirect.github.com/evanw/esbuild/issues/4049))
Previously esbuild would refuse to compile the BigInt literals (such as
`123n`) if they are unsupported in the configured target environment
(such as with `--target=es6`). The rationale was that they cannot be
polyfilled effectively because they change the behavior of JavaScript's
arithmetic operators and JavaScript doesn't have operator overloading.
However, this prevents using esbuild with certain libraries that would
otherwise work if BigInt literals were ignored, such as with old
versions of the [`buffer`
library](https://redirect.github.com/feross/buffer) before the library
fixed support for running in environments without BigInt support. So
with this release, esbuild will now turn BigInt literals into BigInt
constructor calls (so `123n` becomes `BigInt(123)`) and generate a
warning in this case. You can turn off the warning with
`--log-override:bigint=silent` or restore the warning to an error with
`--log-override:bigint=error` if needed.
- Change how `console` API dropping works
([#​4020](https://redirect.github.com/evanw/esbuild/issues/4020))
Previously the `--drop:console` feature replaced all method calls off of
the `console` global with `undefined` regardless of how long the
property access chain was (so it applied to `console.log()` and
`console.log.call(console)` and `console.log.not.a.method()`). However,
it was pointed out that this breaks uses of `console.log.bind(console)`.
That's also incompatible with Terser's implementation of the feature,
which is where this feature originally came from (it does support
`bind`). So with this release, using this feature with esbuild will now
only replace one level of method call (unless extended by `call` or
`apply`) and will replace the method being called with an empty function
in complex cases:
```js
// Original code
const x = console.log('x')
const y = console.log.call(console, 'y')
const z = console.log.bind(console)('z')
// Old output (with --drop-console)
const x = void 0;
const y = void 0;
const z = (void 0)("z");
// New output (with --drop-console)
const x = void 0;
const y = void 0;
const z = (() => {
}).bind(console)("z");
```
This should more closely match Terser's existing behavior.
- Allow BigInt literals as `define` values
With this release, you can now use BigInt literals as define values,
such as with `--define:FOO=123n`. Previously trying to do this resulted
in a syntax error.
- Fix a bug with resolve extensions in `node_modules`
([#​4053](https://redirect.github.com/evanw/esbuild/issues/4053))
The `--resolve-extensions=` option lets you specify the order in which
to try resolving implicit file extensions. For complicated reasons,
esbuild reorders TypeScript file extensions after JavaScript ones inside
of `node_modules` so that JavaScript source code is always preferred to
TypeScript source code inside of dependencies. However, this reordering
had a bug that could accidentally change the relative order of
TypeScript file extensions if one of them was a prefix of the other.
That bug has been fixed in this release. You can see the issue for
details.
- Better minification of statically-determined `switch` cases
([#​4028](https://redirect.github.com/evanw/esbuild/issues/4028))
With this release, esbuild will now try to trim unused code within
`switch` statements when the test expression and `case` expressions are
primitive literals. This can arise when the test expression is an
identifier that is substituted for a primitive literal at compile time.
For example:
```js
// Original code
switch (MODE) {
case 'dev':
installDevToolsConsole()
break
case 'prod':
return
default:
throw new Error
}
// Old output (with --minify '--define:MODE="prod"')
switch("prod"){case"dev":installDevToolsConsole();break;case"prod":return;default:throw
new Error}
// New output (with --minify '--define:MODE="prod"')
return;
```
- Emit `/* @​__KEY__ */` for string literals derived from property
names
([#​4034](https://redirect.github.com/evanw/esbuild/issues/4034))
Property name mangling is an advanced feature that shortens certain
property names for better minification (I say "advanced feature" because
it's very easy to break your code with it). Sometimes you need to store
a property name in a string, such as `obj.get('foo')` instead of
`obj.foo`. JavaScript minifiers such as esbuild and
[Terser](https://terser.org/) have a convention where a `/*
@​__KEY__ */` comment before the string makes it behave like a
property name. So `obj.get(/* @​__KEY__ */ 'foo')` allows the
contents of the string `'foo'` to be shortened.
However, esbuild sometimes itself generates string literals containing
property names when transforming code, such as when lowering class
fields to ES6 or when transforming TypeScript decorators. Previously
esbuild didn't generate its own `/* @​__KEY__ */` comments in this
case, which means that minifying your code by running esbuild again on
its own output wouldn't work correctly (this does not affect people that
both minify and transform their code in a single step).
With this release, esbuild will now generate `/* @​__KEY__ */`
comments for property names in generated string literals. To avoid lots
of unnecessary output for people that don't use this advanced feature,
the generated comments will only be present when the feature is active.
If you want to generate the comments but not actually mangle any
property names, you can use a flag that has no effect such as
`--reserve-props=.`, which tells esbuild to not mangle any property
names (but still activates this feature).
- The `text` loader now strips the UTF-8 BOM if present
([#​3935](https://redirect.github.com/evanw/esbuild/issues/3935))
Some software (such as Notepad on Windows) can create text files that
start with the three bytes `0xEF 0xBB 0xBF`, which is referred to as the
"byte order mark". This prefix is intended to be removed before using
the text. Previously esbuild's `text` loader included this byte sequence
in the string, which turns into a prefix of `\uFEFF` in a JavaScript
string when decoded from UTF-8. With this release, esbuild's `text`
loader will now remove these bytes when they occur at the start of the
file.
- Omit legal comment output files when empty
([#​3670](https://redirect.github.com/evanw/esbuild/issues/3670))
Previously configuring esbuild with `--legal-comment=external` or
`--legal-comment=linked` would always generate a `.LEGAL.txt` output
file even if it was empty. Starting with this release, esbuild will now
only do this if the file will be non-empty. This should result in a more
organized output directory in some cases.
- Update Go from 1.23.1 to 1.23.5
([#​4056](https://redirect.github.com/evanw/esbuild/issues/4056),
[#​4057](https://redirect.github.com/evanw/esbuild/pull/4057))
This should have no effect on existing code as this version change does
not change Go's operating system support. It may remove certain reports
from vulnerability scanners that detect which version of the Go compiler
esbuild uses.
This PR was contributed by
[@​MikeWillCook](https://redirect.github.com/MikeWillCook).
- Allow passing a port of 0 to the development server
([#​3692](https://redirect.github.com/evanw/esbuild/issues/3692))
Unix sockets interpret a port of 0 to mean "pick a random unused port in
the [ephemeral port](https://en.wikipedia.org/wiki/Ephemeral_port)
range". However, esbuild's default behavior when the port is not
specified is to pick the first unused port starting from 8000 and
upward. This is more convenient because port 8000 is typically free, so
you can for example restart the development server and reload your app
in the browser without needing to change the port in the URL. Since
esbuild is written in Go (which does not have optional fields like
JavaScript), not specifying the port in Go means it defaults to 0, so
previously passing a port of 0 to esbuild caused port 8000 to be picked.
Starting with this release, passing a port of 0 to esbuild when using
the CLI or the JS API will now pass port 0 to the OS, which will pick a
random ephemeral port. To make this possible, the `Port` option in the
Go API has been changed from `uint16` to `int` (to allow for additional
sentinel values) and passing a port of -1 in Go now picks a random port.
Both the CLI and JS APIs now remap an explicitly-provided port of 0 into
-1 for the internal Go API.
Another option would have been to change `Port` in Go from `uint16` to
`*uint16` (Go's closest equivalent of `number | undefined`). However,
that would make the common case of providing an explicit port in Go very
awkward as Go doesn't support taking the address of integer constants.
This tradeoff isn't worth it as picking a random ephemeral port is a
rare use case. So the CLI and JS APIs should now match standard Unix
behavior when the port is 0, but you need to use -1 instead with Go API.
- Minification now avoids inlining constants with direct `eval`
([#​4055](https://redirect.github.com/evanw/esbuild/issues/4055))
Direct `eval` can be used to introduce a new variable like this:
```js
const variable = false
;(function () {
eval("var variable = true")
console.log(variable)
})()
```
Previously esbuild inlined `variable` here (which became `false`), which
changed the behavior of the code. This inlining is now avoided, but
please keep in mind that direct `eval` breaks many assumptions that
JavaScript tools hold about normal code (especially when bundling) and I
do not recommend using it. There are usually better alternatives that
have a more localized impact on your code. You can read more about this
here: https://esbuild.github.io/link/direct-eval/
###
[`v0.24.2`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0242)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.24.1...v0.24.2)
- Fix regression with `--define` and `import.meta`
([#​4010](https://redirect.github.com/evanw/esbuild/issues/4010),
[#​4012](https://redirect.github.com/evanw/esbuild/issues/4012),
[#​4013](https://redirect.github.com/evanw/esbuild/pull/4013))
The previous change in version 0.24.1 to use a more expression-like
parser for `define` values to allow quoted property names introduced a
regression that removed the ability to use `--define:import.meta=...`.
Even though `import` is normally a keyword that can't be used as an
identifier, ES modules special-case the `import.meta` expression to
behave like an identifier anyway. This change fixes the regression.
This fix was contributed by
[@​sapphi-red](https://redirect.github.com/sapphi-red).
###
[`v0.24.1`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0241)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.24.0...v0.24.1)
- Allow `es2024` as a target in `tsconfig.json`
([#​4004](https://redirect.github.com/evanw/esbuild/issues/4004))
TypeScript recently [added
`es2024`](https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/#support-for---target-es2024-and---lib-es2024)
as a compilation target, so esbuild now supports this in the `target`
field of `tsconfig.json` files, such as in the following configuration
file:
```json
{
"compilerOptions": {
"target": "ES2024"
}
}
```
As a reminder, the only thing that esbuild uses this field for is
determining whether or not to use legacy TypeScript behavior for class
fields. You can read more in [the
documentation](https://esbuild.github.io/content-types/#tsconfig-json).
This fix was contributed by
[@​billyjanitsch](https://redirect.github.com/billyjanitsch).
- Allow automatic semicolon insertion after `get`/`set`
This change fixes a grammar bug in the parser that incorrectly treated
the following code as a syntax error:
```ts
class Foo {
get
*x() {}
set
*y() {}
}
```
The above code will be considered valid starting with this release. This
change to esbuild follows a [similar change to
TypeScript](https://redirect.github.com/microsoft/TypeScript/pull/60225)
which will allow this syntax starting with TypeScript 5.7.
- Allow quoted property names in `--define` and `--pure`
([#​4008](https://redirect.github.com/evanw/esbuild/issues/4008))
The `define` and `pure` API options now accept identifier expressions
containing quoted property names. Previously all identifiers in the
identifier expression had to be bare identifiers. This change now makes
`--define` and `--pure` consistent with `--global-name`, which already
supported quoted property names. For example, the following is now
possible:
```js
// The following code now transforms to "return true;\n"
console.log(esbuild.transformSync(
`return process.env['SOME-TEST-VAR']`,
{ define: { 'process.env["SOME-TEST-VAR"]': 'true' } },
))
```
Note that if you're passing values like this on the command line using
esbuild's `--define` flag, then you'll need to know how to escape quote
characters for your shell. You may find esbuild's JavaScript API more
ergonomic and portable than writing shell code.
- Minify empty `try`/`catch`/`finally` blocks
([#​4003](https://redirect.github.com/evanw/esbuild/issues/4003))
With this release, esbuild will now attempt to minify empty `try`
blocks:
```js
// Original code
try {} catch { foo() } finally { bar() }
// Old output (with --minify)
try{}catch{foo()}finally{bar()}
// New output (with --minify)
bar();
```
This can sometimes expose additional minification opportunities.
- Include `entryPoint` metadata for the `copy` loader
([#​3985](https://redirect.github.com/evanw/esbuild/issues/3985))
Almost all entry points already include a `entryPoint` field in the
`outputs` map in esbuild's build metadata. However, this wasn't the case
for the `copy` loader as that loader is a special-case that doesn't
behave like other loaders. This release adds the `entryPoint` field in
this case.
- Source mappings may now contain `null` entries
([#​3310](https://redirect.github.com/evanw/esbuild/issues/3310),
[#​3878](https://redirect.github.com/evanw/esbuild/issues/3878))
With this change, sources that result in an empty source map may now
emit a `null` source mapping (i.e. one with a generated position but
without a source index or original position). This change improves
source map accuracy by fixing a problem where minified code from a
source without any source mappings could potentially still be associated
with a mapping from another source file earlier in the generated output
on the same minified line. It manifests as nonsensical files in source
mapped stack traces. Now the `null` mapping "resets" the source map so
that any lookups into the minified code without any mappings resolves to
`null` (which appears as the output file in stack traces) instead of the
incorrect source file.
This change shouldn't affect anything in most situations. I'm only
mentioning it in the release notes in case it introduces a bug with
source mapping. It's part of a work-in-progress future feature that will
let you omit certain unimportant files from the generated source map to
reduce source map size.
- Avoid using the parent directory name for determinism
([#​3998](https://redirect.github.com/evanw/esbuild/issues/3998))
To make generated code more readable, esbuild includes the name of the
source file when generating certain variable names within the file.
Specifically bundling a CommonJS file generates a variable to store the
lazily-evaluated module initializer. However, if a file is named
`index.js` (or with a different extension), esbuild will use the name of
the parent directory instead for a better name (since many packages have
files all named `index.js` but have unique directory names).
This is problematic when the bundle entry point is named `index.js` and
the parent directory name is non-deterministic (e.g. a temporary
directory created by a build script). To avoid non-determinism in
esbuild's output, esbuild will now use `index` instead of the parent
directory in this case. Specifically this will happen if the parent
directory is equal to esbuild's `outbase` API option, which defaults to
the [lowest common
ancestor](https://en.wikipedia.org/wiki/Lowest_common_ancestor) of all
user-specified entry point paths.
- Experimental support for esbuild on NetBSD
([#​3974](https://redirect.github.com/evanw/esbuild/pull/3974))
With this release, esbuild now has a published binary executable for
[NetBSD](https://www.netbsd.org/) in the
[`@esbuild/netbsd-arm64`](https://www.npmjs.com/package/@​esbuild/netbsd-arm64)
npm package, and esbuild's installer has been modified to attempt to use
it when on NetBSD. Hopefully this makes installing esbuild via npm work
on NetBSD. This change was contributed by
[@​bsiegert](https://redirect.github.com/bsiegert).
⚠️ Note: NetBSD is not one of [Node's supported
platforms](https://nodejs.org/api/process.html#process_process_platform),
so installing esbuild may or may not work on NetBSD depending on how
Node has been patched. This is not a problem with esbuild. ⚠️
###
[`v0.24.0`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0240)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.23.1...v0.24.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.23.0` or `~0.23.0`. See npm's documentation about
[semver](https://docs.npmjs.com/cli/v6/using-npm/semver/) for more
information.
- Drop support for older platforms
([#​3902](https://redirect.github.com/evanw/esbuild/pull/3902))
This release drops support for the following operating system:
- macOS 10.15 Catalina
This is because the Go programming language dropped support for this
operating system version in Go 1.23, and this release updates esbuild
from Go 1.22 to Go 1.23. Go 1.23 now requires macOS 11 Big Sur or later.
Note that this only affects the binary esbuild executables that are
published to the esbuild npm package. It's still possible to compile
esbuild's source code for these older operating systems. If you need to,
you can compile esbuild for yourself using an older version of the Go
compiler (before Go version 1.23). That might look something like this:
git clone https://github.com/evanw/esbuild.git
cd esbuild
go build ./cmd/esbuild
./esbuild --version
- Fix class field decorators in TypeScript if `useDefineForClassFields`
is `false`
([#​3913](https://redirect.github.com/evanw/esbuild/issues/3913))
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
([#​3898](https://redirect.github.com/evanw/esbuild/issues/3898))
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`
([#​3915](https://redirect.github.com/evanw/esbuild/issues/3915))
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+
([#​3917](https://redirect.github.com/evanw/esbuild/pull/3917))
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.
This fix was contributed by
[@​Joshix-1](https://redirect.github.com/Joshix-1).
###
[`v0.23.1`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0231)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.23.0...v0.23.1)
- Allow using the `node:` import prefix with `es*` targets
([#​3821](https://redirect.github.com/evanw/esbuild/issues/3821))
The [`node:` prefix on
imports](https://nodejs.org/api/esm.html#node-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 like
this:
```js
// Original code
import fs from 'node:fs'
fs.open
// Old output (with --bundle --format=esm --platform=node
--target=node18,es2022)
import fs from "fs";
fs.open;
// New output (with --bundle --format=esm --platform=node
--target=node18,es2022)
import fs from "node:fs";
fs.open;
```
- Fix a panic when using the CLI with invalid build flags if `--analyze`
is present
([#​3834](https://redirect.github.com/evanw/esbuild/issues/3834))
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
([#​3845](https://redirect.github.com/evanw/esbuild/issues/3845))
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
([#​3838](https://redirect.github.com/evanw/esbuild/issues/3838))
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`
([#​3825](https://redirect.github.com/evanw/esbuild/issues/3825))
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.
###
[`v0.23.0`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0230)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.22.0...v0.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 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](https://docs.npmjs.com/cli/v6/using-npm/semver/) for more
information.
- Revert the recent change to avoid bundling dependencies for node
([#​3819](https://redirect.github.com/evanw/esbuild/issues/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](https://redirect.github.com/evanw/esbuild/issues/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:
```jsx
// Original code
<Foo>
<Bar />
</Foo>
// Old output (with --jsx=preserve)
<Foo><Bar /></Foo>;
// New output (with --jsx=preserve)
<Foo>
<Bar />
</Foo>;
```
###
[`v0.22.0`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0220)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.21.5...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](https://docs.npmjs.com/cli/v6/using-npm/semver/) for more
information.
- Omit packages from bundles by default when targeting node
([#​1874](https://redirect.github.com/evanw/esbuild/issues/1874),
[#​2830](https://redirect.github.com/evanw/esbuild/issues/2830),
[#​2846](https://redirect.github.com/evanw/esbuild/issues/2846),
[#​2915](https://redirect.github.com/evanw/esbuild/issues/2915),
[#​3145](https://redirect.github.com/evanw/esbuild/issues/3145),
[#​3294](https://redirect.github.com/evanw/esbuild/issues/3294),
[#​3323](https://redirect.github.com/evanw/esbuild/issues/3323),
[#​3582](https://redirect.github.com/evanw/esbuild/issues/3582),
[#​3809](https://redirect.github.com/evanw/esbuild/issues/3809),
[#​3815](https://redirect.github.com/evanw/esbuild/issues/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](https://nodejs.org/api/packages.html#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](https://redirect.github.com/evanw/esbuild/issues/3802))
This release drops support for the following operating systems:
- Windows 7
- Windows 8
- Windows Server 2008
- Windows Server 2012
This is because the Go programming language dropped support for these
operating system versions in [Go
1.21](https://go.dev/doc/go1.21#windows), and this release updates
esbuild from Go 1.20 to Go 1.22.
Note that this only affects the binary esbuild executables that are
published to the `esbuild` npm package. It's still possible to compile
esbuild's source code for these older operating systems. If you need to,
you can compile esbuild for yourself using an older version of the Go
compiler (before Go version 1.21). That might look something like this:
git clone https://github.com/evanw/esbuild.git
cd esbuild
go build ./cmd/esbuild
./esbuild.exe --version
In addition, this release increases the minimum required node version
for esbuild's JavaScript API from node 12 to node 18. Node 18 is the
oldest version of node that is still being supported (see node's
[release schedule](https://nodejs.org/en/about/previous-releases) for
more information). This increase is because of an incompatibility
between the JavaScript that the Go compiler generates for the
`esbuild-wasm` package and versions of node before node 17.4
(specifically the `crypto.getRandomValues` function).
- 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](https://redirect.github.com/microsoft/TypeScript/pull/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 OpenBSD on 64-bit ARM
([#​3665](https://redirect.github.com/evanw/esbuild/issues/3665),
[#​3674](https://redirect.github.com/evanw/esbuild/pull/3674))
With this release, you should now be able to install the `esbuild` npm
package in OpenBSD on 64-bit ARM, such as on an Apple device with an M1
chip.
This was contributed by
[@​ikmckenz](https://redirect.github.com/ikmckenz).
- Publish binaries for WASI (WebAssembly System Interface) preview 1
([#​3300](https://redirect.github.com/evanw/esbuild/issues/3300),
[#​3779](https://redirect.github.com/evanw/esbuild/pull/3779))
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](https://go.dev/blog/wasi), 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
([#​3790](https://redirect.github.com/evanw/esbuild/issues/3790))
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
([#​3539](https://redirect.github.com/evanw/esbuild/pull/3539))
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.
This was contributed by
[@​edewit](https://redirect.github.com/edewit).
###
[`v0.21.5`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0215)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.21.4...v0.21.5)
- Fix `Symbol.metadata` on classes without a class decorator
([#​3781](https://redirect.github.com/evanw/esbuild/issues/3781))
This release fixes a bug with esbuild's support for the [decorator
metadata
proposal](https://redirect.github.com/tc39/proposal-decorator-metadata).
Previously esbuild only added the `Symbol.metadata` property to
decorated classes if there was a decorator on the class element itself.
However, the proposal says that the `Symbol.metadata` property should be
present on all classes that have any decorators at all, not just those
with a decorator on the class element itself.
- Allow unknown import attributes to be used with the `copy` loader
([#​3792](https://redirect.github.com/evanw/esbuild/issues/3792))
Import attributes (the `with` keyword on `import` statements) are
allowed to alter how that path is loaded. For example, esbuild cannot
assume that it knows how to load `./bagel.js` as type `bagel`:
```js
// This is an error with "--bundle" without also using
"--external:./bagel.js"
import tasty from "./bagel.js" with { type: "bagel" }
```
Because of that, bundling this code with esbuild is an error unless the
file `./bagel.js` is external to the bundle (such as with `--bundle
--external:./bagel.js`).
However, there is an additional case where it's ok for esbuild to allow
this: if the file is loaded using the `copy` loader. That's because the
`copy` loader behaves similarly to `--external` in that the file is left
external to the bundle. The difference is that the `copy` loader copies
the file into the output folder and rewrites the import path while
`--external` doesn't. That means the following will now work with the
`copy` loader (such as with `--bundle --loader:.bagel=copy`):
```js
// This is no longer an error with "--bundle" and "--loader:.bagel=copy"
import tasty from "./tasty.bagel" with { type: "bagel" }
```
- Support import attributes with glob-style imports
([#​3797](https://redirect.github.com/evanw/esbuild/issues/3797))
This release adds support for import attributes (the `with` option) to
glob-style imports (dynamic imports with certain string literal patterns
as paths). These imports previously didn't support import attributes due
to an oversight. So code like this will now work correctly:
```ts
async function loadLocale(locale: string): Locale {
const data = await import(`./locales/${locale}.data`, { with: { type:
'json' } })
return unpackLocale(locale, data)
}
```
Previously this didn't work even though esbuild normally supports
forcing the JSON loader using an import attribute. Attempting to do this
used to result in the following error:
✘ [ERROR] No loader is configured for ".data" files: locales/en-US.data
example.ts:2:28:
2 │ const data = await import(`./locales/${locale}.data`, { with: {
type: 'json' } })
╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~
In addition, this change means plugins can now access the contents of
`with` for glob-style imports.
- Support `${configDir}` in `tsconfig.json` files
([#​3782](https://redirect.github.com/evanw/esbuild/issues/3782))
This adds support for a new feature from the upcoming TypeScript 5.5
release. The character sequence `${configDir}` is now respected at the
start of `baseUrl` and `paths` values, which are used by esbuild during
bundling to correctly map import paths to file system paths. This
feature lets base `tsconfig.json` files specified via `extends` refer to
the directory of the top-level `tsconfig.json` file. Here is an example:
```json
{
"compilerOptions": {
"paths": {
"js/*": ["${configDir}/dist/js/*"]
}
}
}
```
You can read more in [TypeScript's blog post about their upcoming 5.5
release](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-rc/#the-configdir-template-variable-for-configuration-files).
Note that this feature does not make use of template literals (you need
to use `"${configDir}/dist/js/*"` not `` `${configDir}/dist/js/*` ``).
The syntax for `tsconfig.json` is still just JSON with comments, and
JSON syntax does not allow template literals. This feature only
recognizes `${configDir}` in strings for certain path-like properties,
and only at the beginning of the string.
- Fix internal error with `--supported:object-accessors=false`
([#​3794](https://redirect.github.com/evanw/esbuild/issues/3794))
This release fixes a regression in 0.21.0 where some code that was added
to esbuild's internal runtime library of helper functions for JavaScript
decorators fails to parse when you configure esbuild with
`--supported:object-accessors=false`. The reason is that esbuild
introduced code that does `{ get [name]() {} }` which uses both the
`object-extensions` feature for the `[name]` and the `object-accessors`
feature for the `get`, but esbuild was incorrectly only checking for
`object-extensions` and not for `object-accessors`. Additional tests
have been added to avoid this type of issue in the future. A workaround
for this issue in earlier releases is to also add
`--supported:object-extensions=false`.
###
[`v0.21.4`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0214)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.21.3...v0.21.4)
- Update support for import assertions and import attributes in node
([#​3778](https://redirect.github.com/evanw/esbuild/issues/3778))
Import assertions (the `assert` keyword) have been removed from node
starting in v22.0.0. So esbuild will now strip them and generate a
warning with `--target=node22` or above:
▲ [WARNING] The "assert" keyword is not supported in the configured
target environment ("node22") [assert-to-with]
example.mjs:1:40:
1 │ import json from "esbuild/package.json" assert { type: "json" }
│ ~~~~~~
╵ with
Did you mean to use "with" instead of "assert"?
Import attributes (the `with` keyword) have been backported to node 18
starting in v18.20.0. So esbuild will no longer strip them with
`--target=node18.N` if `N` is 20 or greater.
- Fix `for await` transform when a label is present
This release fixes a bug where the `for await` transform, which wraps
the loop in a `try` statement, previously failed to also move the loop's
label into the `try` statement. This bug only affects code that uses
both of these features in combination. Here's an example of some
affected code:
```js
// Original code
async function test() {
outer: for await (const x of [Promise.resolve([0, 1])]) {
for (const y of x) if (y) break outer
throw 'fail'
}
}
// Old output (with --target=es6)
function test() {
return __async(this, null, function* () {
outer: try {
for (var iter = __forAwait([Promise.resolve([0, 1])]), more, temp,
error; more = !(temp = yield iter.next()).done; more = false) {
const x = temp.value;
for (const y of x) if (y) break outer;
throw "fail";
}
} catch (temp) {
error = [temp];
} finally {
try {
more && (temp = iter.return) && (yield temp.call(iter));
} finally {
if (error)
throw error[0];
}
}
});
}
// New output (with --target=es6)
function test() {
return __async(this, null, function* () {
try {
outer: for (var iter = __forAwait([Promise.resolve([0, 1])]), more,
temp, error; more = !(temp = yield iter.next()).done; more = false) {
const x = temp.value;
for (const y of x) if (y) break outer;
throw "fail";
}
} catch (temp) {
error = [temp];
} finally {
try {
more && (temp = iter.return) && (yield temp.call(iter));
} finally {
if (error)
throw error[0];
}
}
});
}
```
- Do additional constant folding after cross-module enum inlining
([#​3416](https://redirect.github.com/evanw/esbuild/issues/3416),
[#​3425](https://redirect.github.com/evanw/esbuild/issues/3425))
This release adds a few more cases where esbuild does constant folding
after cross-module enum inlining.
```ts
// Original code: enum.ts
export enum Platform {
WINDOWS = 'windows',
MACOS = 'macos',
LINUX = 'linux',
}
// Original code: main.ts
import { Platform } from './enum';
declare const PLATFORM: string;
export function logPlatform() {
if (PLATFORM == Platform.WINDOWS) console.log('Windows');
else if (PLATFORM == Platform.MACOS) console.log('macOS');
else if (PLATFORM == Platform.LINUX) console.log('Linux');
else console.log('Other');
}
// Old output (with --bundle '--define:PLATFORM="macos"' --minify
--format=esm)
function
n(){"windows"=="macos"?console.log("Windows"):"macos"=="macos"?console.log("macOS"):"linux"=="macos"?console.log("Linux"):console.log("Other")}export{n
as logPlatform};
// New output (with --bundle '--define:PLATFORM="macos"' --minify
--format=esm)
function n(){console.log("macOS")}export{n as logPlatform};
```
- Pass import attributes to on-resolve plugins
([#​3384](https://redirect.github.com/evanw/esbuild/issues/3384),
[#​3639](https://redirect.github.com/evanw/esbuild/issues/3639),
[#​3646](https://redirect.github.com/evanw/esbuild/issues/3646))
With this release, on-resolve plugins will now have access to the import
attributes on the import via the `with` property of the arguments
object. This mirrors the `with` property of the arguments object that's
already passed to on-load plugins. In addition, you can now pass `with`
to the `resolve()` API call which will then forward that value on to all
relevant plugins. Here's an example of a plugin that can now be written:
```js
const examplePlugin = {
name: 'Example plugin',
setup(build) {
build.onResolve({ filter: /.*/ }, args => {
if (args.with.type === 'external')
return { external: true }
})
}
}
require('esbuild').build({
stdin: {
contents: `
import foo from "./foo" with { type: "external" }
foo()
`,
},
bundle: true,
format: 'esm',
write: false,
plugins: [examplePlugin],
}).then(result => {
console.log(result.outputFiles[0].text)
})
```
- Formatting support for the `@position-try` rule
([#​3773](https://redirect.github.com/evanw/esbuild/issues/3773))
Chrome shipped this new CSS at-rule in version 125 as part of the [CSS
anchor positioning
API](https://developer.chrome.com/blog/anchor-positioning-api). With
this release, esbuild now knows to expect a declaration list inside of
the `@position-try` body block and will format it appropriately.
- Always allow internal string import and export aliases
([#​3343](https://redirect.github.com/evanw/esbuild/issues/3343))
Import and export names can be string literals in ES2022+. Previously
esbuild forbid any usage of these aliases when the target was below
ES2022. Starting with this release, esbuild will only forbid such usage
when the alias would otherwise end up in output as a string literal.
String literal aliases that are only used internally in the bundle and
are "compiled away" are no longer errors. This makes it possible to use
string literal aliases with esbuild's `inject` feature even when the
target is earlier than ES2022.
###
[`v0.21.3`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0213)
[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.21.2...v0.21.3)
- Implement the decorator metadata proposal
([#​3760](https://redirect.github.com/evanw/esbuil
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about these
updates again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/runtime-env/import-meta-env).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xNjQuMSIsInVwZGF0ZWRJblZlciI6IjM5LjE2NC4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>1 parent 55f10cb commit 35b07abCopy full SHA for 35b07ab
File tree
Expand file treeCollapse file tree
4 files changed
+713
-380
lines changedFilter options
- packages/examples/esbuild-starter-example
Expand file treeCollapse file tree
4 files changed
+713
-380
lines changed+1-1Lines changed: 1 addition & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
29 | 29 | | |
30 | 30 | | |
31 | 31 | | |
32 | | - | |
| 32 | + | |
33 | 33 | | |
34 | 34 | | |
35 | 35 | | |
| |||
0 commit comments