chore(deps): update dependency esbuild to v0.14.42 #1998

renovate · 2022-05-31T18:04:24Z

renovate commented

2022-05-31 18:04:24 +00:00

This PR contains the following updates:

Package	Type	Update	Change
esbuild	devDependencies	patch	`0.14.39` -> `0.14.42`

Release Notes

evanw/esbuild

`v0.14.42`

Compare Source

Fix a parser hang on invalid CSS (#2276)

Previously invalid CSS with unbalanced parentheses could cause esbuild's CSS parser to hang. An example of such an input is the CSS file :x(. This hang has been fixed.
Add support for custom log message levels

This release allows you to override the default log level of esbuild's individual log messages. For example, CSS syntax errors are treated as warnings instead of errors by default because CSS grammar allows for rules containing syntax errors to be ignored. However, if you would like for esbuild to consider CSS syntax errors to be build errors, you can now configure that like this:
- CLI
```
$ esbuild example.css --log-override:css-syntax-error=error
```
- JS API
```
let result = await esbuild.build({
  entryPoints: ['example.css'],
  logOverride: {
    'css-syntax-error': 'error',
  },
})
```
- Go API
```
result := api.Build(api.BuildOptions{
  EntryPoints: []string{"example.ts"},
  LogOverride: map[string]api.LogLevel{
    "css-syntax-error": api.LogLevelError,
  },
})
```
You can also now use this feature to silence warnings that you are not interested in. Log messages are referred to by their identifier. Each identifier is stable (i.e. shouldn't change over time) except there is no guarantee that the log message will continue to exist. A given log message may potentially be removed in the future, in which case esbuild will ignore log levels set for that identifier. The current list of supported log level identifiers for use with this feature can be found below:

JavaScript:
- assign-to-constant
- call-import-namespace
- commonjs-variable-in-esm
- delete-super-property
- direct-eval
- duplicate-case
- duplicate-object-key
- empty-import-meta
- equals-nan
- equals-negative-zero
- equals-new-object
- html-comment-in-js
- impossible-typeof
- private-name-will-throw
- semicolon-after-return
- suspicious-boolean-not
- this-is-undefined-in-esm
- unsupported-dynamic-import
- unsupported-jsx-comment
- unsupported-regexp
- unsupported-require-call
CSS:
- css-syntax-error
- invalid-@charset
- invalid-@import
- invalid-@nest
- invalid-@layer
- invalid-calc
- js-comment-in-css
- unsupported-@charset
- unsupported-@namespace
- unsupported-css-property
Bundler:
- different-path-case
- ignored-bare-import
- ignored-dynamic-import
- import-is-undefined
- package.json
- require-resolve-not-external
- tsconfig.json
Source maps:
- invalid-source-mappings
- sections-in-source-map
- missing-source-map
- unsupported-source-map-comment
Documentation about which identifiers correspond to which log messages will be added in the future, but hasn't been written yet. Note that it's not possible to configure the log level for a build error. This is by design because changing that would cause esbuild to incorrectly proceed in the building process generate invalid build output. You can only configure the log level for non-error log messages (although you can turn non-errors into errors).

`v0.14.41`

Compare Source

Fix a minification regression in 0.14.40 (#2270, #2271, #2273)

Version 0.14.40 substituted string property keys with numeric property keys if the number has the same string representation as the original string. This was done in three places: computed member expressions, object literal properties, and class fields. However, negative numbers are only valid in computed member expressions while esbuild incorrectly applied this substitution for negative numbers in all places. This release fixes the regression by only doing this substitution for negative numbers in computed member expressions.

This fix was contributed by @susiwen8.

`v0.14.40`

Compare Source

Correct esbuild's implementation of "preserveValueImports": true (#2268)

TypeScript's preserveValueImports setting tells the compiler to preserve unused imports, which can sometimes be necessary because otherwise TypeScript will remove unused imports as it assumes they are type annotations. This setting is useful for programming environments that strip TypeScript types as part of a larger code transformation where additional code is appended later that will then make use of those unused imports, such as with Svelte or Vue.

This release fixes an issue where esbuild's implementation of preserveValueImports diverged from the official TypeScript compiler. If the import clause is present but empty of values (even if it contains types), then the import clause should be considered a type-only import clause. This was an oversight, and has now been fixed:
```
// Original code
import "keep"
import { k1 } from "keep"
import k2, { type t1 } from "keep"
import {} from "remove"
import { type t2 } from "remove"

// Old output under "preserveValueImports": true
import "keep";
import { k1 } from "keep";
import k2, {} from "keep";
import {} from "remove";
import {} from "remove";

// New output under "preserveValueImports": true (matches the TypeScript compiler)
import "keep";
import { k1 } from "keep";
import k2 from "keep";
```
Avoid regular expression syntax errors in older browsers (#2215)

Previously esbuild always passed JavaScript regular expression literals through unmodified from the input to the output. This is undesirable when the regular expression uses newer features that the configured target environment doesn't support. For example, the d flag (i.e. the match indices feature) is new in ES2022 and doesn't work in older browsers. If esbuild generated a regular expression literal containing the d flag, then older browsers would consider esbuild's output to be a syntax error and none of the code would run.

With this release, esbuild now detects when an unsupported feature is being used and converts the regular expression literal into a new RegExp() constructor instead. One consequence of this is that the syntax error is transformed into a run-time error, which allows the output code to run (and to potentially handle the run-time error). Another consequence of this is that it allows you to include a polyfill that overwrites the RegExp constructor in older browsers with one that supports modern features. Note that esbuild does not handle polyfills for you, so you will need to include a RegExp polyfill yourself if you want one.
```
// Original code
console.log(/b/d.exec('abc').indices)

// New output (with --target=chrome90)
console.log(/b/d.exec("abc").indices);

// New output (with --target=chrome89)
console.log(new RegExp("b", "d").exec("abc").indices);
```
This is currently done transparently without a warning. If you would like to debug this transformation to see where in your code esbuild is transforming regular expression literals and why, you can pass --log-level=debug to esbuild and review the information present in esbuild's debug logs.
Add Opera to more internal feature compatibility tables (#2247, #2252)

The internal compatibility tables that esbuild uses to determine which environments support which features are derived from multiple sources. Most of it is automatically derived from these ECMAScript compatibility tables, but missing information is manually copied from MDN, GitHub PR comments, and various other websites. Version 0.14.35 of esbuild introduced Opera as a possible target environment which was automatically picked up by the compatibility table script, but the manually-copied information wasn't updated to include Opera. This release fixes this omission so Opera feature compatibility should now be accurate.

This was contributed by @lbwa.
Ignore EPERM errors on directories (#2261)

Previously bundling with esbuild when inside a sandbox environment which does not have permission to access the parent directory did not work because esbuild would try to read the directory to search for a node_modules folder and would then fail the build when that failed. In practice this caused issues with running esbuild with sandbox-exec on macOS. With this release, esbuild will treat directories with permission failures as empty to allow for the node_modules search to continue past the denied directory and into its parent directory. This means it should now be possible to bundle with esbuild in these situations. This fix is similar to the fix in version 0.9.1 but is for EPERM while that fix was for EACCES.
Remove an irrelevant extra "use strict" directive (#2264)

The presence of a "use strict" directive in the output file is controlled by the presence of one in the entry point. However, there was a bug that would include one twice if the output format is ESM. This bug has been fixed.
Minify strings into integers inside computed properties (#2214)

This release now minifies a["0"] into a[0] when the result is equivalent:
```
// Original code
console.log(x['0'], { '0': x }, class { '0' = x })

// Old output (with --minify)
console.log(x["0"],{"0":x},class{"0"=x});

// New output (with --minify)
console.log(x[0],{0:x},class{0=x});
```
This transformation currently only happens when the numeric property represents an integer within the signed 32-bit integer range.

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.

If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [esbuild](https://github.com/evanw/esbuild) | devDependencies | patch | [`0.14.39` -> `0.14.42`](https://renovatebot.com/diffs/npm/esbuild/0.14.39/0.14.42) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.14.42`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01442) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.41...v0.14.42) - Fix a parser hang on invalid CSS ([#2276](https://github.com/evanw/esbuild/issues/2276)) Previously invalid CSS with unbalanced parentheses could cause esbuild's CSS parser to hang. An example of such an input is the CSS file `:x(`. This hang has been fixed. - Add support for custom log message levels This release allows you to override the default log level of esbuild's individual log messages. For example, CSS syntax errors are treated as warnings instead of errors by default because CSS grammar allows for rules containing syntax errors to be ignored. However, if you would like for esbuild to consider CSS syntax errors to be build errors, you can now configure that like this: - CLI ```sh $ esbuild example.css --log-override:css-syntax-error=error ``` - JS API ```js let result = await esbuild.build({ entryPoints: ['example.css'], logOverride: { 'css-syntax-error': 'error', }, }) ``` - Go API ```go result := api.Build(api.BuildOptions{ EntryPoints: []string{"example.ts"}, LogOverride: map[string]api.LogLevel{ "css-syntax-error": api.LogLevelError, }, }) ``` You can also now use this feature to silence warnings that you are not interested in. Log messages are referred to by their identifier. Each identifier is stable (i.e. shouldn't change over time) except there is no guarantee that the log message will continue to exist. A given log message may potentially be removed in the future, in which case esbuild will ignore log levels set for that identifier. The current list of supported log level identifiers for use with this feature can be found below: **JavaScript:** - `assign-to-constant` - `call-import-namespace` - `commonjs-variable-in-esm` - `delete-super-property` - `direct-eval` - `duplicate-case` - `duplicate-object-key` - `empty-import-meta` - `equals-nan` - `equals-negative-zero` - `equals-new-object` - `html-comment-in-js` - `impossible-typeof` - `private-name-will-throw` - `semicolon-after-return` - `suspicious-boolean-not` - `this-is-undefined-in-esm` - `unsupported-dynamic-import` - `unsupported-jsx-comment` - `unsupported-regexp` - `unsupported-require-call` **CSS:** - `css-syntax-error` - `invalid-@charset` - `invalid-@import` - `invalid-@nest` - `invalid-@layer` - `invalid-calc` - `js-comment-in-css` - `unsupported-@charset` - `unsupported-@namespace` - `unsupported-css-property` **Bundler:** - `different-path-case` - `ignored-bare-import` - `ignored-dynamic-import` - `import-is-undefined` - `package.json` - `require-resolve-not-external` - `tsconfig.json` **Source maps:** - `invalid-source-mappings` - `sections-in-source-map` - `missing-source-map` - `unsupported-source-map-comment` Documentation about which identifiers correspond to which log messages will be added in the future, but hasn't been written yet. Note that it's not possible to configure the log level for a build error. This is by design because changing that would cause esbuild to incorrectly proceed in the building process generate invalid build output. You can only configure the log level for non-error log messages (although you can turn non-errors into errors). ### [`v0.14.41`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01441) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.40...v0.14.41) - Fix a minification regression in 0.14.40 ([#2270](https://github.com/evanw/esbuild/issues/2270), [#2271](https://github.com/evanw/esbuild/issues/2271), [#2273](https://github.com/evanw/esbuild/pull/2273)) Version 0.14.40 substituted string property keys with numeric property keys if the number has the same string representation as the original string. This was done in three places: computed member expressions, object literal properties, and class fields. However, negative numbers are only valid in computed member expressions while esbuild incorrectly applied this substitution for negative numbers in all places. This release fixes the regression by only doing this substitution for negative numbers in computed member expressions. This fix was contributed by [@susiwen8](https://github.com/susiwen8). ### [`v0.14.40`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01440) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.39...v0.14.40) - Correct esbuild's implementation of `"preserveValueImports": true` ([#2268](https://github.com/evanw/esbuild/issues/2268)) TypeScript's [`preserveValueImports` setting](https://www.typescriptlang.org/tsconfig#preserveValueImports) tells the compiler to preserve unused imports, which can sometimes be necessary because otherwise TypeScript will remove unused imports as it assumes they are type annotations. This setting is useful for programming environments that strip TypeScript types as part of a larger code transformation where additional code is appended later that will then make use of those unused imports, such as with [Svelte](https://svelte.dev/) or [Vue](https://vuejs.org/). This release fixes an issue where esbuild's implementation of `preserveValueImports` diverged from the official TypeScript compiler. If the import clause is present but empty of values (even if it contains types), then the import clause should be considered a type-only import clause. This was an oversight, and has now been fixed: ```ts // Original code import "keep" import { k1 } from "keep" import k2, { type t1 } from "keep" import {} from "remove" import { type t2 } from "remove" // Old output under "preserveValueImports": true import "keep"; import { k1 } from "keep"; import k2, {} from "keep"; import {} from "remove"; import {} from "remove"; // New output under "preserveValueImports": true (matches the TypeScript compiler) import "keep"; import { k1 } from "keep"; import k2 from "keep"; ``` - Avoid regular expression syntax errors in older browsers ([#2215](https://github.com/evanw/esbuild/issues/2215)) Previously esbuild always passed JavaScript regular expression literals through unmodified from the input to the output. This is undesirable when the regular expression uses newer features that the configured target environment doesn't support. For example, the `d` flag (i.e. the [match indices feature](https://v8.dev/features/regexp-match-indices)) is new in ES2022 and doesn't work in older browsers. If esbuild generated a regular expression literal containing the `d` flag, then older browsers would consider esbuild's output to be a syntax error and none of the code would run. With this release, esbuild now detects when an unsupported feature is being used and converts the regular expression literal into a `new RegExp()` constructor instead. One consequence of this is that the syntax error is transformed into a run-time error, which allows the output code to run (and to potentially handle the run-time error). Another consequence of this is that it allows you to include a polyfill that overwrites the `RegExp` constructor in older browsers with one that supports modern features. Note that esbuild does not handle polyfills for you, so you will need to include a `RegExp` polyfill yourself if you want one. ```js // Original code console.log(/b/d.exec('abc').indices) // New output (with --target=chrome90) console.log(/b/d.exec("abc").indices); // New output (with --target=chrome89) console.log(new RegExp("b", "d").exec("abc").indices); ``` This is currently done transparently without a warning. If you would like to debug this transformation to see where in your code esbuild is transforming regular expression literals and why, you can pass `--log-level=debug` to esbuild and review the information present in esbuild's debug logs. - Add Opera to more internal feature compatibility tables ([#2247](https://github.com/evanw/esbuild/issues/2247), [#2252](https://github.com/evanw/esbuild/pull/2252)) The internal compatibility tables that esbuild uses to determine which environments support which features are derived from multiple sources. Most of it is automatically derived from [these ECMAScript compatibility tables](https://kangax.github.io/compat-table/), but missing information is manually copied from [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/), GitHub PR comments, and various other websites. Version 0.14.35 of esbuild introduced Opera as a possible target environment which was automatically picked up by the compatibility table script, but the manually-copied information wasn't updated to include Opera. This release fixes this omission so Opera feature compatibility should now be accurate. This was contributed by [@lbwa](https://github.com/lbwa). - Ignore `EPERM` errors on directories ([#2261](https://github.com/evanw/esbuild/issues/2261)) Previously bundling with esbuild when inside a sandbox environment which does not have permission to access the parent directory did not work because esbuild would try to read the directory to search for a `node_modules` folder and would then fail the build when that failed. In practice this caused issues with running esbuild with `sandbox-exec` on macOS. With this release, esbuild will treat directories with permission failures as empty to allow for the `node_modules` search to continue past the denied directory and into its parent directory. This means it should now be possible to bundle with esbuild in these situations. This fix is similar to the fix in version 0.9.1 but is for `EPERM` while that fix was for `EACCES`. - Remove an irrelevant extra `"use strict"` directive ([#2264](https://github.com/evanw/esbuild/issues/2264)) The presence of a `"use strict"` directive in the output file is controlled by the presence of one in the entry point. However, there was a bug that would include one twice if the output format is ESM. This bug has been fixed. - Minify strings into integers inside computed properties ([#2214](https://github.com/evanw/esbuild/issues/2214)) This release now minifies `a["0"]` into `a[0]` when the result is equivalent: ```js // Original code console.log(x['0'], { '0': x }, class { '0' = x }) // Old output (with --minify) console.log(x["0"],{"0":x},class{"0"=x}); // New output (with --minify) console.log(x[0],{0:x},class{0=x}); ``` This transformation currently only happens when the numeric property represents an integer within the signed 32-bit integer range. </details> --- ### 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. --- - [ ] If you want to rebase/retry this PR, click this checkbox. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

renovate added the

dependencies

label 2022-05-31 18:04:24 +00:00

renovate added 1 commit 2022-05-31 18:04:24 +00:00

continuous-integration/drone/pr Build is passing Details

72d02a2ad8 chore(deps): update dependency esbuild to v0.14.42

frederick commented

2022-05-31 18:54:45 +00:00

Hi renovate!

Thank you for creating a PR!

I've deployed the changes of this PR on a preview environment under this URL: https://1998-renovate-esbuild-0-x--vikunja-frontend-preview.netlify.app

You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.

Have a nice day!

Beep boop, I'm a bot.

Hi renovate! Thank you for creating a PR! I've deployed the changes of this PR on a preview environment under this URL: https://1998-renovate-esbuild-0-x--vikunja-frontend-preview.netlify.app You can use this url to view the changes live and test them out. You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/. Have a nice day! > Beep boop, I'm a bot.

konrad merged commit 6940e6cc7f into main

2022-05-31 19:20:35 +00:00

konrad referenced this issue from a commit

2022-05-31 19:20:35 +00:00

chore(deps): update dependency esbuild to v0.14.42 (#1998)

konrad deleted branch renovate/esbuild-0.x

2022-05-31 19:20:35 +00:00

This repo is archived. You cannot comment on pull requests.

No reviewers