chore(deps-dev): bump esbuild from 0.18.11 to 0.19.2

[dependabot]

Bumps esbuild from 0.18.11 to 0.19.2.

Release notes

Sourced from esbuild's releases.

v0.19.2

• Update how CSS nesting is parsed again

  CSS nesting syntax has been changed again, and esbuild has been updated to match. Type selectors may now be used with CSS nesting:

  .foo {
    div {
      color: red;
    }
  }

  Previously this was disallowed in the CSS specification because it's ambiguous whether an identifier is a declaration or a nested rule starting with a type selector without requiring unbounded lookahead in the parser. It has now been allowed because the CSS working group has decided that requiring unbounded lookahead is acceptable after all.

  Note that this change means esbuild no longer considers any existing browser to support CSS nesting since none of the existing browsers support this new syntax. CSS nesting will now always be transformed when targeting a browser. This situation will change in the future as browsers add support for this new syntax.

• Fix a scope-related bug with --drop-labels= (#3311)

  The recently-released --drop-labels= feature previously had a bug where esbuild's internal scope stack wasn't being restored properly when a statement with a label was dropped. This could manifest as a tree-shaking issue, although it's possible that this could have also been causing other subtle problems too. The bug has been fixed in this release.

• Make renamed CSS names unique across entry points (#3295)

  Previously esbuild's generated names for local names in CSS were only unique within a given entry point (or across all entry points when code splitting was enabled). That meant that building multiple entry points with esbuild could result in local names being renamed to the same identifier even when those entry points were built simultaneously within a single esbuild API call. This problem was especially likely to happen with minification enabled. With this release, esbuild will now avoid renaming local names from two separate entry points to the same name if those entry points were built with a single esbuild API call, even when code splitting is disabled.

• Fix CSS ordering bug with @layer before @import

  CSS lets you put @layer rules before @import rules to define the order of layers in a stylesheet. Previously esbuild's CSS bundler incorrectly ordered these after the imported files because before the introduction of cascade layers to CSS, imported files could be bundled by removing the @import rules and then joining files together in the right order. But with @layer, CSS files may now need to be split apart into multiple pieces in the bundle. For example:

  /* Original code */
  @layer start;
  @import "data:text/css,@layer inner.start;";
  @import "data:text/css,@layer inner.end;";
  @layer end;
  /* Old output (with --bundle) */
  @​layer inner.start;
  @​layer inner.end;
  @​layer start;
  @​layer end;
  /* New output (with --bundle) */
  @​layer start;
  @​layer inner.start;
  @​layer inner.end;
  @​layer end;
  

• Unwrap nested duplicate @media rules (#3226)

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.19.2

• Update how CSS nesting is parsed again

  CSS nesting syntax has been changed again, and esbuild has been updated to match. Type selectors may now be used with CSS nesting:

  .foo {
    div {
      color: red;
    }
  }

  Previously this was disallowed in the CSS specification because it's ambiguous whether an identifier is a declaration or a nested rule starting with a type selector without requiring unbounded lookahead in the parser. It has now been allowed because the CSS working group has decided that requiring unbounded lookahead is acceptable after all.

  Note that this change means esbuild no longer considers any existing browser to support CSS nesting since none of the existing browsers support this new syntax. CSS nesting will now always be transformed when targeting a browser. This situation will change in the future as browsers add support for this new syntax.

• Fix a scope-related bug with --drop-labels= (#3311)

  The recently-released --drop-labels= feature previously had a bug where esbuild's internal scope stack wasn't being restored properly when a statement with a label was dropped. This could manifest as a tree-shaking issue, although it's possible that this could have also been causing other subtle problems too. The bug has been fixed in this release.

• Make renamed CSS names unique across entry points (#3295)

  Previously esbuild's generated names for local names in CSS were only unique within a given entry point (or across all entry points when code splitting was enabled). That meant that building multiple entry points with esbuild could result in local names being renamed to the same identifier even when those entry points were built simultaneously within a single esbuild API call. This problem was especially likely to happen with minification enabled. With this release, esbuild will now avoid renaming local names from two separate entry points to the same name if those entry points were built with a single esbuild API call, even when code splitting is disabled.

• Fix CSS ordering bug with @layer before @import

  CSS lets you put @layer rules before @import rules to define the order of layers in a stylesheet. Previously esbuild's CSS bundler incorrectly ordered these after the imported files because before the introduction of cascade layers to CSS, imported files could be bundled by removing the @import rules and then joining files together in the right order. But with @layer, CSS files may now need to be split apart into multiple pieces in the bundle. For example:

  /* Original code */
  @layer start;
  @import "data:text/css,@layer inner.start;";
  @import "data:text/css,@layer inner.end;";
  @layer end;
  /* Old output (with --bundle) */
  @​layer inner.start;
  @​layer inner.end;
  @​layer start;
  @​layer end;
  /* New output (with --bundle) */
  @​layer start;
  @​layer inner.start;
  @​layer inner.end;
  @​layer end;
  

... (truncated)

Commits

• 09a1001 publish 0.19.2 to npm
• 4d9b764 fix #3311: pop scope after --drop-labels= runs
• f2d23b2 fix some typos
• e76780c css: further changes to css nesting syntax
• 71f4a5a update compat-table (note: css nesting changed)
• eb667c3 css: try to merge adjacent @layer rules together
• f759693 css: fix ordering with @layer before @import
• c73f0f8 css: extract wrapping logic to a helper function
• a05a2f9 css: make source index on compile results optional
• bb16fb7 css: parser separates layers pre/post @import
• 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 show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Looks like esbuild is up-to-date now, so this is no longer needed.