Update dependency esbuild to v0.9.6

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	`0.9.2` -> `0.9.6`

Release Notes

evanw/esbuild

### [`v0.9.6`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#096) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.9.5...v0.9.6) - Expose build options to plugins ([#373](https://togithub.com/evanw/esbuild/issues/373)) Plugins can now access build options from within the plugin using the `initialOptions` property. For example: ```js let nodeEnvPlugin = { name: 'node-env', setup(build) { const options = build.initialOptions options.define = options.define || {} options.define['process.env.NODE_ENV'] = options.minify ? '"production"' : '"development"' }, } ``` - Fix an edge case with the object spread transform ([#1017](https://togithub.com/evanw/esbuild/issues/1017)) This release fixes esbuild's object spread transform in cases where property assignment could be different than property definition. For example: ```js console.log({ get x() {}, ...{x: 1}, }) ``` This should print `{x: 1}` but transforming this through esbuild with `--target=es6` causes the resulting code to throw an error. The problem is that esbuild currently transforms this code to a call to `Object.assign` and that uses property assignment semantics, which causes the assignment to throw (since you can't assign to a getter-only property). With this release, esbuild will now transform this into code that manually loops over the properties and copies them over one-by-one using `Object.defineProperty` instead. This uses property definition semantics which better matches the specification. - Fix a TypeScript parsing edge case with arrow function return types ([#1016](https://togithub.com/evanw/esbuild/issues/1016)) This release fixes the following TypeScript parsing edge case: ```ts ():Array=>{return [1]} ``` This was tripping up esbuild's TypeScript parser because the `>=` token was split into a `>` token and a `=` token because the `>` token is needed to close the type parameter list, but the `=` token was not being combined with the following `>` token to form a `=>` token. This is normally not an issue because there is normally a space in between the `>` and the `=>` tokens here. The issue only happened when the spaces were removed. This bug has been fixed. Now after the `>=` token is split, esbuild will expand the `=` token into the following characters if possible, which can result in a `=>`, `==`, or `===` token. - Enable faster synchronous transforms under a flag ([#1000](https://togithub.com/evanw/esbuild/issues/1000)) Currently the synchronous JavaScript API calls `transformSync` and `buildSync` spawn a new child process on every call. This is due to limitations with node's `child_process` API. Doing this means `transformSync` and `buildSync` are much slower than `transform` and `build`, which share the same child process across calls. There was previously a workaround for this limitation that uses node's `worker_threads` API and atomics to block the main thread while asynchronous communication happens in a worker, but that was reverted due to a bug in node's `worker_threads` implementation. Now that this bug has been fixed by node, I am re-enabling this workaround. This should result in `transformSync` and `buildSync` being much faster. This approach is experimental and is currently only enabled if the `ESBUILD_WORKER_THREADS` environment variable is present. If this use case matters to you, please try it out and let me know if you find any problems with it. - Update how optional chains are compiled to match new V8 versions ([#1019](https://togithub.com/evanw/esbuild/issues/1019)) An optional chain is an expression that uses the `?.` operator, which roughly avoids evaluation of the right-hand side if the left-hand side is `null` or `undefined`. So `a?.b` is basically equivalent to `a == null ? void 0 : a.b`. When the language target is set to `es2019` or below, esbuild will transform optional chain expressions into equivalent expressions that do not use the `?.` operator. This transform is designed to match the behavior of V8 exactly, and is designed to do something similar to the equivalent transform done by the TypeScript compiler. However, V8 has recently changed its behavior in two cases: - Forced call of an optional member expression should propagate the object to the method: ```js const o = { m() { return this; } }; assert((o?.m)() === o); ``` V8 bug: - Optional call of `eval` must be an indirect eval: ```js globalThis.a = 'global'; var b = (a => eval?.('a'))('local'); assert(b === 'global'); ``` V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=10630 This release changes esbuild's transform to match V8's new behavior. The transform in the TypeScript compiler is still emulating the old behavior as of version 4.2.3, so these syntax forms should be avoided in TypeScript code for portability. ### [`v0.9.5`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#095) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.9.4...v0.9.5) - Fix parsing of the `[dir]` placeholder ([#1013](https://togithub.com/evanw/esbuild/issues/1013)) The entry names feature in the previous release accidentally didn't include parsing for the `[dir]` placeholder, so the `[dir]` placeholder was passed through verbatim into the resulting output paths. This release fixes the bug, which means you can now use the `[dir]` placeholder. Sorry about the oversight. ### [`v0.9.4`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#094) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.9.3...v0.9.4) - Enable hashes in entry point file paths ([#518](https://togithub.com/evanw/esbuild/issues/518)) This release adds the new `--entry-names=` flag. It's similar to the `--chunk-names=` and `--asset-names=` flags except it sets the output paths for entry point files. The pattern defaults to `[dir]/[name]` which should be equivalent to the previous entry point output path behavior, so this should be a backward-compatible change. This change has the following consequences: - It is now possible for entry point output paths to contain a hash. For example, this now happens if you pass `--entry-names=[dir]/[name]-[hash]`. This means you can now use esbuild to generate output files such that all output paths have a hash in them, which means it should now be possible to serve the output files with an infinite cache lifetime so they are only downloaded once and then cached by the browser forever. - It is now possible to prevent the generation of subdirectories inside the output directory. Previously esbuild replicated the directory structure of the input entry points relative to the `outbase` directory (which defaults to the [lowest common ancestor](https://en.wikipedia.org/wiki/Lowest_common_ancestor) directory across all entry points). This value is substituted into the newly-added `[dir]` placeholder. But you can now omit it by omitting that placeholder, like this: `--entry-names=[name]`. - Source map names should now be equal to the corresponding output file name plus an additional `.map` extension. Previously the hashes were content hashes, so the source map had a different hash than the corresponding output file because they had different contents. Now they have the same hash so finding the source map should now be easier (just add `.map`). - Due to the way the new hashing algorithm works, all chunks can now be generated fully in parallel instead of some chunks having to wait until their dependency chunks have been generated first. The import paths for dependency chunks are now swapped in after chunk generation in a second pass (detailed below). This could theoretically result in a speedup although I haven't done any benchmarks around this. Implementing this feature required overhauling how hashes are calculated to prevent the chicken-and-egg hashing problem due to dynamic imports, which can cause cycles in the import graph of the resulting output files when code splitting is enabled. Since generating a hash involved first hashing all of your dependencies, you could end up in a situation where you needed to know the hash to calculate the hash (if a file was a dependency of itself). The hashing algorithm now works in three steps (potentially subject to change in the future): 1. The initial versions of all output files are generated in parallel, with temporary paths used for any imports of other output files. Each temporary path is a randomly-generated string that is unique for each output file. An initial source map is also generated at this step if source maps are enabled. The hash for the first step includes: the raw content of the output file excluding the temporary paths, the relative file paths of all input files present in that output file, the relative output path for the resulting output file (with `[hash]` for the hash that hasn't been computed yet), and contents of the initial source map. 2. After the initial versions of all output files have been generated, calculate the final hash and final output path for each output file. Calculating the final output path involves substituting the final hash for the `[hash]` placeholder in the entry name template. The hash for the second step includes: the hash from the first step for this file and all of its transitive dependencies. 3. After all output files have a final output path, the import paths in each output file for importing other output files are substituted. Source map offsets also have to be adjusted because the final output path is likely a different length than the temporary path used in the first step. This is also done in parallel for each output file. This whole algorithm roughly means the hash of a given output file should change if an only if any input file in that output file or any output file it depends on is changed. So the output path and therefore the browser's cache key should not change for a given output file in between builds if none of the relevant input files were changed. - Fix importing a path containing a `?` character on Windows ([#989](https://togithub.com/evanw/esbuild/issues/989)) On Windows, the `?` character is not allowed in path names. This causes esbuild to fail to import paths containing this character. This is usually fine because people don't put `?` in their file names for this reason. However, the import paths for some ancient CSS code contains the `?` character as a hack to work around a bug in Internet Explorer: ```css @font-face { src: url("./icons.eot?#iefix") format('embedded-opentype'), url("./icons.woff2") format('woff2'), url("./icons.woff") format('woff'), url("./icons.ttf") format('truetype'), url("./icons.svg#icons") format('svg'); } ``` The intent is for the bundler to ignore the `?#iefix` part. However, there may actually be a file called `icons.eot?#iefix` on the file system so esbuild checks the file system for both `icons.eot?#iefix` and `icons.eot`. This check was triggering this issue. With this release, an invalid path is considered the same as a missing file so bundling code like this should now work on Windows. - Parse and ignore the deprecated `@-ms-viewport` CSS rule ([#997](https://togithub.com/evanw/esbuild/issues/997)) The [`@viewport`](https://www.w3.org/TR/css-device-adapt-1/#atviewport-rule) rule has been deprecated and removed from the web. Modern browsers now completely ignore this rule. However, in theory it sounds like would still work for mobile versions of Internet Explorer, if those still exist. The library contains an instance of the `@-ms-viewport` rule and it currently causes a warning with esbuild, so this release adds support for parsing this rule to disable the warning. - Avoid mutating the binary executable file in place ([#963](https://togithub.com/evanw/esbuild/issues/963)) This release changes the install script for the `esbuild` npm package to use the "rename a temporary file" approach instead of the "write the file directly" approach to replace the `esbuild` command stub file with the real binary executable. This should hopefully work around a problem with the [pnpm](https://pnpm.js.org/) package manager and its use of hard links. - Avoid warning about potential issues with `sideEffects` in packages ([#999](https://togithub.com/evanw/esbuild/issues/999)) Bare imports such as `import "foo"` mean the package is only imported for its side effects. Doing this when the package contains `"sideEffects": false` in `package.json` causes a warning because it means esbuild will not import the file since it has been marked as having no side effects, even though the import statement clearly expects it to have side effects. This is usually caused by an incorrect `sideEffects` annotation in the package. However, this warning is not immediately actionable if the file containing the import statement is itself in a package. So with this release, esbuild will no longer issue this warning if the file containing the import is inside a `node_modules` folder. Note that even though the warning is no longer there, this situation can still result in a broken bundle if the `sideEffects` annotation is incorrect. ### [`v0.9.3`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#093) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.9.2...v0.9.3) - Fix path resolution with the `exports` field for scoped packages This release fixes a bug where the `exports` field in `package.json` files was not being detected for scoped packages (i.e. packages of the form `@scope/pkg-name` instead of just `pkg-name`). The `exports` field should now be respected for these kinds of packages. - Improved error message in `exports` failure case Node's new [conditional exports feature](https://nodejs.org/docs/latest/api/packages.html#packages_conditional_exports) can be non-intuitive and hard to use. Now that esbuild supports this feature (as of version 0.9.0), you can get into a situation where it's impossible to import a package if the package's `exports` field in its `package.json` file isn't configured correctly. Previously the error message for this looked like this: > entry.js:1:7: error: Could not resolve "jotai" (mark it as external to exclude it from the bundle) 1 │ import 'jotai' ╵ ~~~~~~~ node_modules/jotai/package.json:16:13: note: The path "." is not exported by "jotai" 16 │ "exports": { ╵ ^ With this release, the error message will now provide additional information about why the package cannot be imported: > entry.js:1:7: error: Could not resolve "jotai" (mark it as external to exclude it from the bundle) 1 │ import 'jotai' ╵ ~~~~~~~ node_modules/jotai/package.json:16:13: note: The path "." is not currently exported by package "jotai" 16 │ "exports": { ╵ ^ node_modules/jotai/package.json:18:9: note: None of the conditions provided ("module", "require", "types") match any of the currently active conditions ("browser", "default", "import") 18 │ ".": { ╵ ^ entry.js:1:7: note: Consider using a "require()" call to import this package 1 │ import 'jotai' ╵ ~~~~~~~ In this case, one solution could be import this module using `require()` since this package provides an export for the `require` condition. Another solution could be to pass `--conditions=module` to esbuild since this package provides an export for the `module` condition (the `types` condition is likely not valid JavaScript code). This problem occurs because this package doesn't provide an import path for ESM code using the `import` condition and also doesn't provide a fallback import path using the `default` condition. - Mention glob syntax in entry point error messages ([#976](https://togithub.com/evanw/esbuild/issues/976)) In this release, including a `*` in the entry point path now causes the failure message to tell you that glob syntax must be expanded first before passing the paths to esbuild. People that hit this are usually converting an existing CLI command to a JavaScript API call and don't know that glob expansion is done by their shell instead of by esbuild. An appropriate fix is to use a library such as [`glob`](https://www.npmjs.com/package/glob) to expand the glob pattern first before passing the paths to esbuild. - Raise certain VM versions in the JavaScript feature compatibility table JavaScript VM feature compatibility data is derived from this dataset: . The scripts that process the dataset expand the data to include all VM versions that support a given feature (e.g. `chrome44`, `chrome45`, `chrome46`, ...) so esbuild takes the minimum observed version as the first version for which the feature is supported. However, some features can have subtests that each check a different aspect of the feature. In this case the desired version is the minimum version within each individual subtest, but the maximum of those versions across all subtests (since esbuild should only use the feature if it works in all cases). Previously esbuild computed the minimum version across all subtests, but now esbuild computes the maximum version across all subtests. This means esbuild will now lower JavaScript syntax in more cases. - Mention the configured target environment in error messages ([#975](https://togithub.com/evanw/esbuild/issues/975)) Using newer JavaScript syntax with an older target environment (e.g. `chrome10`) can cause a build error if esbuild doesn't support transforming that syntax such that it is compatible with that target environment. Previously the error message was generic but with this release, the target environment is called outp explicitly in the error message. This is helpful if esbuild is being wrapped by some other tool since the other tool can obscure what target environment is actually being passed to esbuild. - Fix an issue with Unicode and source maps This release fixes a bug where non-ASCII content that ended up in an output file but that was not part of an input file could throw off source mappings. An example of this would be passing a string containing non-ASCII characters to the `globalName` setting with the `minify` setting active and the `charset` setting set to `utf8`. The conditions for this bug are fairly specific and unlikely to be hit, so it's unsurprising that this issue hasn't been discovered earlier. It's also unlikely that this issue affected real-world code. The underlying cause is that while the meaning of column numbers in source maps is undefined in the specification, in practice most tools treat it as the number of UTF-16 code units from the start of the line. The bug happened because column increments for outside-of-file characters were incorrectly counted using byte offsets instead of UTF-16 code unit counts.

Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

gagoar / use-herald-action

Update dependency esbuild to v0.9.6 #401

Release Notes

Renovate configuration

Codecov Report