chore(deps-dev): bump esbuild from 0.14.21 to 0.14.22

[dependabot]

Bumps esbuild from 0.14.21 to 0.14.22.

Release notes

Sourced from esbuild's releases.

v0.14.22

• Preserve whitespace for token lists that look like CSS variable declarations (#2020)

  Previously esbuild removed the whitespace after the CSS variable declaration in the following CSS:

  /* Original input */
  @supports (--foo: ){html{background:green}}
  /* Previous output */
  @​supports (--foo:){html{background:green}}

  However, that broke rendering in Chrome as it caused Chrome to ignore the entire rule. This did not break rendering in Firefox and Safari, so there's a browser bug either with Chrome or with both Firefox and Safari. In any case, esbuild now preserves whitespace after the CSS variable declaration in this case.

• Ignore legal comments when merging adjacent duplicate CSS rules (#2016)

  This release now generates more compact minified CSS when there are legal comments in between two adjacent rules with identical content:

  /* Original code */
  a { color: red }
  /* @preserve */
  b { color: red }
  /* Old output (with --minify) /
  a{color:red}/ @​preserve */b{color:red}
  /* New output (with --minify) /
  a,b{color:red}/ @​preserve */

• Block onResolve and onLoad until onStart ends (#1967)

  This release changes the semantics of the onStart callback. All onStart callbacks from all plugins are run concurrently so that a slow plugin doesn't hold up the entire build. That's still the case. However, previously the only thing waiting for the onStart callbacks to finish was the end of the build. This meant that onResolve and/or onLoad callbacks could sometimes run before onStart had finished. This was by design but violated user expectations. With this release, all onStart callbacks must finish before any onResolve and/or onLoad callbacks are run.

• Add a self-referential default export to the JS API (#1897)

  Some people try to use esbuild's API using import esbuild from 'esbuild' instead of import * as esbuild from 'esbuild' (i.e. using a default import instead of a namespace import). There is no default export so that wasn't ever intended to work. But it would work sometimes depending on which tools you used and how they were configured so some people still wrote code this way. This release tries to make that work by adding a self-referential default export that is equal to esbuild's module namespace object.

  More detail: The published package for esbuild's JS API is in CommonJS format, although the source code for esbuild's JS API is in ESM format. The original ESM code for esbuild's JS API has no export named default so using a default import like this doesn't work with Babel-compatible toolchains (since they respect the semantics of the original ESM code). However, it happens to work with node-compatible toolchains because node's implementation of importing CommonJS from ESM broke compatibility with existing conventions and automatically creates a default export which is set to module.exports. This is an unfortunate compatibility headache because it means the default import only works sometimes. This release tries to fix this by explicitly creating a self-referential default export. It now doesn't matter if you do esbuild.build(), esbuild.default.build(), or esbuild.default.default.build() because they should all do the same thing. Hopefully this means people don't have to deal with this problem anymore.

• Handle write errors when esbuild's child process is killed (#2007)

  If you type Ctrl+C in a terminal when a script that uses esbuild's JS library is running, esbuild's child process may be killed before the parent process. In that case calls to the write() syscall may fail with an EPIPE error. Previously this resulted in an uncaught exception because esbuild didn't handle this case. Starting with this release, esbuild should now catch these errors and redirect them into a general The service was stopped error which should be returned from whatever top-level API calls were in progress.

• Better error message when browser WASM bugs are present (#1863)

  Safari's WebAssembly implementation appears to be broken somehow, at least when running esbuild. Sometimes this manifests as a stack overflow and sometimes as a Go panic. Previously a Go panic resulted in the error message Can't find variable: fs but this should now result in the Go panic being printed to the console. Using esbuild's WebAssembly library in Safari is still broken but now there's a more helpful error message.

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.22

• Preserve whitespace for token lists that look like CSS variable declarations (#2020)

  Previously esbuild removed the whitespace after the CSS variable declaration in the following CSS:

  /* Original input */
  @supports (--foo: ){html{background:green}}
  /* Previous output */
  @​supports (--foo:){html{background:green}}

  However, that broke rendering in Chrome as it caused Chrome to ignore the entire rule. This did not break rendering in Firefox and Safari, so there's a browser bug either with Chrome or with both Firefox and Safari. In any case, esbuild now preserves whitespace after the CSS variable declaration in this case.

• Ignore legal comments when merging adjacent duplicate CSS rules (#2016)

  This release now generates more compact minified CSS when there are legal comments in between two adjacent rules with identical content:

  /* Original code */
  a { color: red }
  /* @preserve */
  b { color: red }
  /* Old output (with --minify) /
  a{color:red}/ @​preserve */b{color:red}
  /* New output (with --minify) /
  a,b{color:red}/ @​preserve */

• Block onResolve and onLoad until onStart ends (#1967)

  This release changes the semantics of the onStart callback. All onStart callbacks from all plugins are run concurrently so that a slow plugin doesn't hold up the entire build. That's still the case. However, previously the only thing waiting for the onStart callbacks to finish was the end of the build. This meant that onResolve and/or onLoad callbacks could sometimes run before onStart had finished. This was by design but violated user expectations. With this release, all onStart callbacks must finish before any onResolve and/or onLoad callbacks are run.

• Add a self-referential default export to the JS API (#1897)

  Some people try to use esbuild's API using import esbuild from 'esbuild' instead of import * as esbuild from 'esbuild' (i.e. using a default import instead of a namespace import). There is no default export so that wasn't ever intended to work. But it would work sometimes depending on which tools you used and how they were configured so some people still wrote code this way. This release tries to make that work by adding a self-referential default export that is equal to esbuild's module namespace object.

  More detail: The published package for esbuild's JS API is in CommonJS format, although the source code for esbuild's JS API is in ESM format. The original ESM code for esbuild's JS API has no export named default so using a default import like this doesn't work with Babel-compatible toolchains (since they respect the semantics of the original ESM code). However, it happens to work with node-compatible toolchains because node's implementation of importing CommonJS from ESM broke compatibility with existing conventions and automatically creates a default export which is set to module.exports. This is an unfortunate compatibility headache because it means the default import only works sometimes. This release tries to fix this by explicitly creating a self-referential default export. It now doesn't matter if you do esbuild.build(), esbuild.default.build(), or esbuild.default.default.build() because they should all do the same thing. Hopefully this means people don't have to deal with this problem anymore.

• Handle write errors when esbuild's child process is killed (#2007)

  If you type Ctrl+C in a terminal when a script that uses esbuild's JS library is running, esbuild's child process may be killed before the parent process. In that case calls to the write() syscall may fail with an EPIPE error. Previously this resulted in an uncaught exception because esbuild didn't handle this case. Starting with this release, esbuild should now catch these errors and redirect them into a general The service was stopped error which should be returned from whatever top-level API calls were in progress.

• Better error message when browser WASM bugs are present (#1863)

  Safari's WebAssembly implementation appears to be broken somehow, at least when running esbuild. Sometimes this manifests as a stack overflow and sometimes as a Go panic. Previously a Go panic resulted in the error message Can't find variable: fs but this should now result in the Go panic being printed to the console. Using esbuild's WebAssembly library in Safari is still broken but now there's a more helpful error message.

... (truncated)

Commits

• b26003f publish 0.14.22 to npm
• 7473276 destructuring should be a side effect (#1183)
• 8debc09 fix #1863: make fs.writeSync work in the browser
• efe61ee fix browser tests
• 0af35be fix #2007: swallow write syscall errors on child
• be8ad84 fix #1897: add a self-referential default export
• 9abb31d fix #1967: onResolve + onLoad now block on onStart
• 5406bb7 update to Go 1.17.7
• 9f5e8c8 fix #2020: keep whitespace in "@​supports" css vars
• 28e0ded fix #2016: ignore legal comments in between rules
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)