codecov[bot]
commented
3 years ago Codecov Report
Merging #54 (d5aab83) into master (09d8682) will not change coverage. The diff coverage is
n/a.
@@ Coverage Diff @@
## master #54 +/- ##
=======================================
Coverage 86.36% 86.36%
=======================================
Files 2 2
Lines 44 44
Branches 6 6
=======================================
Hits 38 38
Partials 6 6 Continue to review full report at Codecov.
Legend - Click here to learn more
Ξ = absolute <relative> (impact),ΓΈ = not affected,? = missing dataPowered by Codecov. Last update 09d8682...d5aab83. Read the comment docs.
github-actions[bot]
This PR contains the following updates:
0.13.6->0.13.8Release Notes
evanw/esbuild
### [`v0.13.8`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0138) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.7...v0.13.8) - Fix `super` inside arrow function inside lowered `async` function ([#1425](https://togithub.com/evanw/esbuild/issues/1425)) When an `async` function is transformed into a regular function for target environments that don't support `async` such as `--target=es6`, references to `super` inside that function must be transformed too since the `async`-to-regular function transformation moves the function body into a nested function, so the `super` references are no longer syntactically valid. However, this transform didn't handle an edge case and `super` references inside of an arrow function were overlooked. This release fixes this bug: ```js // Original code class Foo extends Bar { async foo() { return () => super.foo() } } // Old output (with --target=es6) class Foo extends Bar { foo() { return __async(this, null, function* () { return () => super.foo(); }); } } // New output (with --target=es6) class Foo extends Bar { foo() { var __super = (key) => super[key]; return __async(this, null, function* () { return () => __super("foo").call(this); }); } } ``` - Remove the implicit `/` after `[dir]` in entry names ([#1661](https://togithub.com/evanw/esbuild/issues/1661)) The "entry names" feature lets you customize the way output file names are generated. The `[dir]` and `[name]` placeholders are filled in with the directory name and file name of the corresponding entry point file, respectively. Previously `--entry-names=[dir]/[name]` and `--entry-names=[dir][name]` behaved the same because the value used for `[dir]` always had an implicit trailing slash, since it represents a directory. However, some people want to be able to remove the file name with `--entry-names=[dir]` and the implicit trailing slash gets in the way. With this release, you can now use the `[dir]` placeholder without an implicit trailing slash getting in the way. For example, the command `esbuild foo/bar/index.js --outbase=. --outdir=out --entry-names=[dir]` previously generated the file `out/foo/bar/.js` but will now generate the file `out/foo/bar.js`. ### [`v0.13.7`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0137) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.6...v0.13.7) - Minify CSS alpha values correctly ([#1682](https://togithub.com/evanw/esbuild/issues/1682)) When esbuild uses the `rgba()` syntax for a color instead of the 8-character hex code (e.g. when `target` is set to Chrome 61 or earlier), the 0-to-255 integer alpha value must be printed as a floating-point fraction between 0 and 1. The fraction was only printed to three decimal places since that is the minimal number of decimal places required for all 256 different alpha values to be uniquely determined. However, using three decimal places does not necessarily result in the shortest result. For example, `128 / 255` is `0.5019607843137255` which is printed as `".502"` using three decimal places, but `".5"` is equivalent because `round(0.5 * 255) == 128`, so printing `".5"` would be better. With this release, esbuild will always use the minimal numeric representation for the alpha value: ```css /* Original code */ a { color: #FF800080 } /* Old output (with --minify --target=chrome61) */ a{color:rgba(255,128,0,.502)} /* New output (with --minify --target=chrome61) */ a{color:rgba(255,128,0,.5)} ``` - Match node's behavior for core module detection ([#1680](https://togithub.com/evanw/esbuild/issues/1680)) Node has a hard-coded list of core modules (e.g. `fs`) that, when required, short-circuit the module resolution algorithm and instead return the corresponding internal core module object. When you pass `--platform=node` to esbuild, esbuild also implements this short-circuiting behavior and doesn't try to bundle these import paths. This was implemented in esbuild using the existing `external` feature (e.g. essentially `--external:fs`). However, there is an edge case where esbuild's `external` feature behaved differently than node. Modules specified via esbuild's `external` feature also cause all sub-paths to be excluded as well, so for example `--external:foo` excludes both `foo` and `foo/bar` from the bundle. However, node's core module check is only an exact equality check, so for example `fs` is a core module and bypasses the module resolution algorithm but `fs/foo` is not a core module and causes the module resolution algorithm to search the file system. This behavior can be used to load a module on the file system with the same name as one of node's core modules. For example, `require('fs/')` will load the module `fs` from the file system instead of loading node's core `fs` module. With this release, esbuild will now match node's behavior in this edge case. This means the external modules that are automatically added by `--platform=node` now behave subtly differently than `--external:`, which allows code that relies on this behavior to be bundled correctly. - Fix WebAssembly builds on Go 1.17.2+ ([#1684](https://togithub.com/evanw/esbuild/pull/1684)) Go 1.17.2 introduces a change (specifically a [fix for CVE-2021-38297](https://go-review.googlesource.com/c/go/+/354591/)) that causes Go's WebAssembly bootstrap script to throw an error when it's run in situations with many environment variables. One such situation is when the bootstrap script is run inside [GitHub Actions](https://togithub.com/features/actions). This change was introduced because the bootstrap script writes a copy of the environment variables into WebAssembly memory without any bounds checking, and writing more than 4096 bytes of data ends up writing past the end of the buffer and overwriting who-knows-what. So throwing an error in this situation is an improvement. However, this breaks esbuild which previously (at least seemingly) worked fine. With this release, esbuild's WebAssembly bootstrap script that calls out to Go's WebAssembly bootstrap script will now delete all environment variables except for the ones that esbuild checks for, of which there are currently only four: `NO_COLOR`, `NODE_PATH`, `npm_config_user_agent`, and `WT_SESSION`. This should avoid a crash when esbuild is built using Go 1.17.2+ and should reduce the likelihood of memory corruption when esbuild is built using Go 1.17.1 or earlier. This release also updates the Go version that esbuild ships with to version 1.17.2. Note that this problem only affects the `esbuild-wasm` package. The `esbuild` package is not affected. See also: - [https://github.com/golang/go/issues/48797](https://togithub.com/golang/go/issues/48797) - [https://github.com/golang/go/issues/49011](https://togithub.com/golang/go/issues/49011)Configuration
π Schedule: At any time (no schedule defined).
π¦ Automerge: Disabled by config. Please merge this manually once you are satisfied.
β» Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
π Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by WhiteSource Renovate. View repository job log here.