codecov[bot]
commented
3 years ago Codecov Report
Merging #47 (3b0bd30) into master (babada7) will not change coverage. The diff coverage is
n/a.
@@ Coverage Diff @@
## master #47 +/- ##
=======================================
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 babada7...3b0bd30. Read the comment docs.
github-actions[bot]
This PR contains the following updates:
0.13.3->0.13.6Release Notes
evanw/esbuild
### [`v0.13.6`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0136) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.5...v0.13.6) - Emit decorators for `declare` class fields ([#1675](https://togithub.com/evanw/esbuild/issues/1675)) In version 3.7, TypeScript introduced the `declare` keyword for class fields that avoids generating any code for that field: ```ts // TypeScript input class Foo { a: number declare b: number } // JavaScript output class Foo { a; } ``` However, it turns out that TypeScript still emits decorators for these omitted fields. With this release, esbuild will now do this too: ```ts // TypeScript input class Foo { @decorator a: number; @decorator declare b: number; } // Old JavaScript output class Foo { a; } __decorateClass([ decorator ], Foo.prototype, "a", 2); // New JavaScript output class Foo { a; } __decorateClass([ decorator ], Foo.prototype, "a", 2); __decorateClass([ decorator ], Foo.prototype, "b", 2); ``` - Experimental support for esbuild on NetBSD ([#1624](https://togithub.com/evanw/esbuild/pull/1624)) With this release, esbuild now has a published binary executable for [NetBSD](https://www.netbsd.org/) in the [`esbuild-netbsd-64`](https://www.npmjs.com/package/esbuild-netbsd-64) 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 [@gdt](https://togithub.com/gdt). ⚠️ 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. ⚠️ - Disable the "esbuild was bundled" warning if `ESBUILD_BINARY_PATH` is provided ([#1678](https://togithub.com/evanw/esbuild/pull/1678)) The `ESBUILD_BINARY_PATH` environment variable allows you to substitute an alternate binary executable for esbuild's JavaScript API. This is useful in certain cases such as when debugging esbuild. The JavaScript API has some code that throws an error if it detects that it was bundled before being run, since bundling prevents esbuild from being able to find the path to its binary executable. However, that error is unnecessary if `ESBUILD_BINARY_PATH` is present because an alternate path has been provided. This release disables the warning when `ESBUILD_BINARY_PATH` is present so that esbuild can be used when bundled as long as you also manually specify `ESBUILD_BINARY_PATH`. This change was contributed by [@heypiotr](https://togithub.com/heypiotr). - Remove unused `catch` bindings when minifying ([#1660](https://togithub.com/evanw/esbuild/pull/1660)) With this release, esbuild will now remove unused `catch` bindings when minifying: ```js // Original code try { throw 0; } catch (e) { } // Old output (with --minify) try{throw 0}catch(t){} // New output (with --minify) try{throw 0}catch{} ``` This takes advantage of the new [optional catch binding](https://togithub.com/tc39/proposal-optional-catch-binding) syntax feature that was introduced in ES2019. This minification rule is only enabled when optional catch bindings are supported by the target environment. Specifically, it's not enabled when using `--target=es2018` or older. Make sure to set esbuild's `target` setting correctly when minifying if the code will be running in an older JavaScript environment. This change was contributed by [@sapphi-red](https://togithub.com/sapphi-red). ### [`v0.13.5`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0135) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.4...v0.13.5) - Improve watch mode accuracy ([#1113](https://togithub.com/evanw/esbuild/issues/1113)) Watch mode is enabled by `--watch` and causes esbuild to become a long-running process that automatically rebuilds output files when input files are changed. It's implemented by recording all calls to esbuild's internal file system interface and then invalidating the build whenever these calls would return different values. For example, a call to esbuild's internal `ReadFile()` function is considered to be different if either the presence of the file has changed (e.g. the file didn't exist before but now exists) or the presence of the file stayed the same but the content of the file has changed. Previously esbuild's watch mode operated at the `ReadFile()` and `ReadDirectory()` level. When esbuild checked whether a directory entry existed or not (e.g. whether a directory contains a `node_modules` subdirectory or a `package.json` file), it called `ReadDirectory()` which then caused the build to depend on that directory's set of entries. This meant the build would be invalidated even if a new unrelated entry was added or removed, since that still changes the set of entries. This is problematic when using esbuild in environments that constantly create and destroy temporary directory entries in your project directory. In that case, esbuild's watch mode would constantly rebuild as the directory was constantly considered to be dirty. With this release, watch mode now operates at the `ReadFile()` and `ReadDirectory().Get()` level. So when esbuild checks whether a directory entry exists or not, the build should now only depend on the presence status for that one directory entry. This should avoid unnecessary rebuilds due to unrelated directory entries being added or removed. The log messages generated using `--watch` will now also mention the specific directory entry whose presence status was changed if a build is invalidated for this reason. Note that this optimization does not apply to plugins using the `watchDirs` return value because those paths are only specified at the directory level and do not describe individual directory entries. You can use `watchFiles` or `watchDirs` on the individual entries inside the directory to get a similar effect instead. - Disallow certain uses of `<` in `.mts` and `.cts` files The upcoming version 4.5 of TypeScript is introducing the `.mts` and `.cts` extensions that turn into the `.mjs` and `.cjs` extensions when compiled. However, unlike the existing `.ts` and `.tsx` extensions, expressions that start with `<` are disallowed when they would be ambiguous depending on whether they are parsed in `.ts` or `.tsx` mode. The ambiguity is caused by the overlap between the syntax for JSX elements and the old deprecated syntax for type casts: | Syntax | `.ts` | `.tsx` | `.mts`/`.cts` | |-------------------------------|----------------------|------------------|----------------------| | `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.