[Snyk] Upgrade esbuild from 0.21.4 to 0.21.5 #108
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR was automatically created by Snyk using the credentials of a real user.
![snyk-top-banner](https://github.com/andygongea/OWASP-Benchmark/assets/818805/c518c423-16fe-447e-b67f-ad5a49b5d123)
Snyk has created this PR to upgrade esbuild from 0.21.4 to 0.21.5.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
The recommended version is 1 version ahead of your current version.
The recommended version was released on 21 days ago.
Release notes
Package name: esbuild
Fix
Symbol.metadata
on classes without a class decorator (#3781)This release fixes a bug with esbuild's support for the decorator metadata proposal. 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 theSymbol.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)Import attributes (the
with
keyword onimport
statements) are allowed to alter how that path is loaded. For example, esbuild cannot assume that it knows how to load./bagel.js
as typebagel
: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 thecopy
loader behaves similarly to--external
in that the file is left external to the bundle. The difference is that thecopy
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 thecopy
loader (such as with--bundle --loader:.bagel=copy
):Support import attributes with glob-style imports (#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: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:
This adds support for a new feature from the upcoming TypeScript 5.5 release. The character sequence
${configDir}
is now respected at the start ofbaseUrl
andpaths
values, which are used by esbuild during bundling to correctly map import paths to file system paths. This feature lets basetsconfig.json
files specified viaextends
refer to the directory of the top-leveltsconfig.json
file. Here is an example:You can read more in TypeScript's blog post about their upcoming 5.5 release. Note that this feature does not make use of template literals (you need to use
"${configDir}/dist/js/*"
not`${configDir}/dist/js/*`
). The syntax fortsconfig.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)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 theobject-extensions
feature for the[name]
and theobject-accessors
feature for theget
, but esbuild was incorrectly only checking forobject-extensions
and not forobject-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
.Update support for import assertions and import attributes in node (#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]
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
ifN
is 20 or greater.Fix
for await
transform when a label is presentThis release fixes a bug where the
for await
transform, which wraps the loop in atry
statement, previously failed to also move the loop's label into thetry
statement. This bug only affects code that uses both of these features in combination. Here's an example of some affected 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, #3425)
This release adds a few more cases where esbuild does constant folding after cross-module enum inlining.
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, #3639, #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 thewith
property of the arguments object that's already passed to on-load plugins. In addition, you can now passwith
to theresolve()
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:name: 'Example plugin',
setup(build) {
build.onResolve({ filter: /.*/ }, args => {
if (args.with.type === 'external')
return { external: true }
})
}
}
require('esbuild').build({
stdin: {
contents:
</span> <span class="pl-s"> import foo from "./foo" with { type: "external" }</span> <span class="pl-s"> foo()</span> <span class="pl-s">
,},
bundle: true,
format: 'esm',
write: false,
plugins: [examplePlugin],
}).then(result => {
console.log(result.outputFiles[0].text)
})
Formatting support for the
@ position-try
rule (#3773)Chrome shipped this new CSS at-rule in version 125 as part of the CSS 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)
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.Important
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information: