Bump esbuild from 0.11.23 to 0.12.0

[dependabot]

Bumps esbuild from 0.11.23 to 0.12.0.

Release notes

Sourced from esbuild's releases.

v0.12.0

This release contains backwards-incompatible changes. Since esbuild is before version 1.0.0, these changes have been released as a new minor version to reflect this (as recommended by npm). You should either be pinning the exact version of esbuild in your package.json file or be using a version range syntax that only accepts patch upgrades such as ~0.11.0. See the documentation about semver for more information.

The breaking changes in this release relate to CSS import order and also build scenarios where both the inject and define API options are used (see below for details). These breaking changes are as follows:

• Fix bundled CSS import order (#465)

  JS and CSS use different import ordering algorithms. In JS, importing a file that has already been imported is a no-op but in CSS, importing a file that has already been imported re-imports the file. A simple way to imagine this is to view each @import rule in CSS as being replaced by the contents of that file similar to #include in C/C++. However, this is incorrect in the case of @import cycles because it would cause infinite expansion. A more accurate way to imagine this is that in CSS, a file is evaluated at the last @import location while in JS, a file is evaluated at the first import location.

  Previously esbuild followed JS import order rules for CSS but now esbuild will follow CSS import order rules. This is a breaking change because it means your CSS may behave differently when bundled. Note that CSS import order rules are somewhat unintuitive because evaluation order matters. In CSS, using @import multiple times can end up unintentionally erasing overriding styles. For example, consider the following files:

  /* entry.css */
  @import "./color.css";
  @import "./background.css";

  /* color.css */
  @import "./reset.css";
  body {
    color: white;
  }

  /* background.css */
  @import "./reset.css";
  body {
    background: black;
  }

  /* reset.css */
  body {
    background: white;
    color: black;
  }

  Because of how CSS import order works, entry.css will now be bundled like this:

  /* color.css */
  body {
    color: white;
  }
  /* reset.css */

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.12.0

This release contains backwards-incompatible changes. Since esbuild is before version 1.0.0, these changes have been released as a new minor version to reflect this (as recommended by npm). You should either be pinning the exact version of esbuild in your package.json file or be using a version range syntax that only accepts patch upgrades such as ~0.11.0. See the documentation about semver for more information.

The breaking changes in this release relate to CSS import order and also build scenarios where both the inject and define API options are used (see below for details). These breaking changes are as follows:

• Fix bundled CSS import order (#465)

  JS and CSS use different import ordering algorithms. In JS, importing a file that has already been imported is a no-op but in CSS, importing a file that has already been imported re-imports the file. A simple way to imagine this is to view each @import rule in CSS as being replaced by the contents of that file similar to #include in C/C++. However, this is incorrect in the case of @import cycles because it would cause infinite expansion. A more accurate way to imagine this is that in CSS, a file is evaluated at the last @import location while in JS, a file is evaluated at the first import location.

  Previously esbuild followed JS import order rules for CSS but now esbuild will follow CSS import order rules. This is a breaking change because it means your CSS may behave differently when bundled. Note that CSS import order rules are somewhat unintuitive because evaluation order matters. In CSS, using @import multiple times can end up unintentionally erasing overriding styles. For example, consider the following files:

  /* entry.css */
  @import "./color.css";
  @import "./background.css";

  /* color.css */
  @import "./reset.css";
  body {
    color: white;
  }

  /* background.css */
  @import "./reset.css";
  body {
    background: black;
  }

  /* reset.css */
  body {
    background: white;
    color: black;
  }

  Because of how CSS import order works, entry.css will now be bundled like this:

  /* color.css */
  body {
    color: white;
  }

... (truncated)

Commits

• 4cc1001 publish 0.12.0 to npm
• a076216 update the browser compat table
• d92616e fixes after landing #1261
• f158b78 Apply defines before injected global variables (#1261)
• 88a434e Breaking changes to fix CSS import issues (#1293)
• 7136d84 cli: respect the "NO_COLOR" convention
• See full diff 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)

[ankoh]

@dependabot rebase