[Snyk] Upgrade esbuild from 0.21.3 to 0.21.4 #106
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.3 to 0.21.4.
ℹ️ 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
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.Implement the decorator metadata proposal (#3760)
This release implements the decorator metadata proposal, which is a sub-proposal of the decorators proposal. Microsoft shipped the decorators proposal in TypeScript 5.0 and the decorator metadata proposal in TypeScript 5.2, so it's important that esbuild also supports both of these features. Here's a quick example:
Symbol.metadata ??= Symbol('Symbol.metadata')
const track = (_, context) => {
(context.metadata.names ||= []).push(context.name)
}
class Foo {
@track foo = 1
@track bar = 2
}
// Prints ["foo", "bar"]
console.log(Foo[Symbol.metadata].names)
This proposal has been marked as "stage 3" which means "recommended for implementation". However, it's still a work in progress and isn't a part of JavaScript yet, so keep in mind that any code that uses JavaScript decorator metadata may need to be updated as the feature continues to evolve. If/when that happens, I will update esbuild's implementation to match the specification. I will not be supporting old versions of the specification.
Fix bundled decorators in derived classes (#3768)
In certain cases, bundling code that uses decorators in a derived class with a class body that references its own class name could previously generate code that crashes at run-time due to an incorrect variable name. This problem has been fixed. Here is an example of code that was compiled incorrectly before this fix:
Fix
tsconfig.json
files inside symlinked directories (#3767)This release fixes an issue with a scenario involving a
tsconfig.json
file thatextends
another file from within a symlinked directory that uses thepaths
feature. In that case, the implicitbaseURL
value should be based on the real path (i.e. after expanding all symbolic links) instead of the original path. This was already done for other files that esbuild resolves but was not yet done fortsconfig.json
because it's special-cased (the regular path resolver can't be used because the information insidetsconfig.json
is involved in path resolution). Note that this fix no longer applies if the--preserve-symlinks
setting is enabled.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: