npm(deps-dev): bump esbuild from 0.8.57 to 0.9.6

[dependabot]

Bumps esbuild from 0.8.57 to 0.9.6.

Release notes

Sourced from esbuild's releases.

v0.9.6

• Expose build options to plugins (#373)

  Plugins can now access build options from within the plugin using the initialOptions property. For example:

  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)

  This release fixes esbuild's object spread transform in cases where property assignment could be different than property definition. For example:

  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)

  This release fixes the following TypeScript parsing edge case:

  ():Array<number>=>{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)

  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.

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.9.6

• Expose build options to plugins (#373)

  Plugins can now access build options from within the plugin using the initialOptions property. For example:

  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)

  This release fixes esbuild's object spread transform in cases where property assignment could be different than property definition. For example:

  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)

  This release fixes the following TypeScript parsing edge case:

  ():Array<number>=>{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)

  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.

... (truncated)

Commits

• 3c679d5 publish 0.9.6 to npm
• d790be4 fix #373: expose build options to plugins
• d012ce1 implement recent v8 changes to optional chaining behavior (#1022)
• e5127cb re-enable the "worker_threads" sync workaround (#1021)
• 9d44e66 do not use Object.assign for object spread (#1018)
• 412d3da fix stack parsing to skip internal "node:" lines
• 512eb19 fix #1016: parse issue with ts arrow return types
• 3c3a299 publish 0.9.5 to npm
• 514a7b0 fix #1013: parsing for the "[dir]" placeholder
• 237870f publish 0.9.4 to npm
• 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)

[dependabot]

Superseded by #6.