Skip to content

Bump esbuild from 0.18.13 to 0.18.14 in /it/typescript#2945

Merged
github-actions[bot] merged 1 commit into
mainfrom
dependabot/npm_and_yarn/it/typescript/esbuild-0.18.14
Jul 18, 2023
Merged

Bump esbuild from 0.18.13 to 0.18.14 in /it/typescript#2945
github-actions[bot] merged 1 commit into
mainfrom
dependabot/npm_and_yarn/it/typescript/esbuild-0.18.14

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jul 18, 2023

Copy link
Copy Markdown
Contributor

Bumps esbuild from 0.18.13 to 0.18.14.

Release notes

Sourced from esbuild's releases.

v0.18.14

  • Implement local CSS names (#20)

    This release introduces two new loaders called global-css and local-css and two new pseudo-class selectors :local() and :global(). This is a partial implementation of the popular CSS modules approach for avoiding unintentional name collisions in CSS. I'm not calling this feature "CSS modules" because although some people in the community call it that, other people in the community have started using "CSS modules" to refer to something completely different and now CSS modules is an overloaded term.

    Here's how this new local CSS name feature works with esbuild:

    • Identifiers that look like .className and #idName are global with the global-css loader and local with the local-css loader. Global identifiers are the same across all files (the way CSS normally works) but local identifiers are different between different files. If two separate CSS files use the same local identifier .button, esbuild will automatically rename one of them so that they don't collide. This is analogous to how esbuild automatically renames JS local variables with the same name in separate JS files to avoid name collisions.

    • It only makes sense to use local CSS names with esbuild when you are also using esbuild's bundler to bundle JS files that import CSS files. When you do that, esbuild will generate one export for each local name in the CSS file. The JS code can import these names and use them when constructing HTML DOM. For example:

      // app.js
      import { outerShell } from './app.css'
      const div = document.createElement('div')
      div.className = outerShell
      document.body.appendChild(div)
      /* app.css */
      .outerShell {
        position: absolute;
        inset: 0;
      }

      When you bundle this with esbuild app.js --bundle --loader:.css=local-css --outdir=out you'll now get this (notice how the local CSS name outerShell has been renamed):

      // out/app.js
      (() => {
        // app.css
        var outerShell = "app_outerShell";
      // app.js
      var div = document.createElement("div");
      div.className = outerShell;
      document.body.appendChild(div);
      })();

      /* out/app.css */
      .app_outerShell {
        position: absolute;
        inset: 0;
      }

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.18.14

  • Implement local CSS names (#20)

    This release introduces two new loaders called global-css and local-css and two new pseudo-class selectors :local() and :global(). This is a partial implementation of the popular CSS modules approach for avoiding unintentional name collisions in CSS. I'm not calling this feature "CSS modules" because although some people in the community call it that, other people in the community have started using "CSS modules" to refer to something completely different and now CSS modules is an overloaded term.

    Here's how this new local CSS name feature works with esbuild:

    • Identifiers that look like .className and #idName are global with the global-css loader and local with the local-css loader. Global identifiers are the same across all files (the way CSS normally works) but local identifiers are different between different files. If two separate CSS files use the same local identifier .button, esbuild will automatically rename one of them so that they don't collide. This is analogous to how esbuild automatically renames JS local variables with the same name in separate JS files to avoid name collisions.

    • It only makes sense to use local CSS names with esbuild when you are also using esbuild's bundler to bundle JS files that import CSS files. When you do that, esbuild will generate one export for each local name in the CSS file. The JS code can import these names and use them when constructing HTML DOM. For example:

      // app.js
      import { outerShell } from './app.css'
      const div = document.createElement('div')
      div.className = outerShell
      document.body.appendChild(div)
      /* app.css */
      .outerShell {
        position: absolute;
        inset: 0;
      }

      When you bundle this with esbuild app.js --bundle --loader:.css=local-css --outdir=out you'll now get this (notice how the local CSS name outerShell has been renamed):

      // out/app.js
      (() => {
        // app.css
        var outerShell = "app_outerShell";
      // app.js
      var div = document.createElement("div");
      div.className = outerShell;
      document.body.appendChild(div);
      })();

      /* out/app.css */
      .app_outerShell {
        position: absolute;
        inset: 0;
      }

... (truncated)

Commits
  • af0fe32 publish 0.18.14 to npm
  • fd1ddfa css: implement bare :global and :local
  • 5c23bee css: match other local/global implementations
  • 3dc8372 css: disallow , in :local and :global
  • 7db1264 css: add a global-css loader with global symbols
  • 9ff3860 css: source map tests can now be more accurate
  • feea007 css: emit mappings for calc reductions
  • e3f6eb8 css: emit mappings for tokens
  • 9410725 css: emit mappings for subclass selectors
  • c6e14ef css: emit mappings for nesting selectors
  • Additional commits viewable in compare view

Dependabot compatibility score

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)

Bumps [esbuild](https://github.com/evanw/esbuild) from 0.18.13 to 0.18.14.
- [Release notes](https://github.com/evanw/esbuild/releases)
- [Changelog](https://github.com/evanw/esbuild/blob/main/CHANGELOG.md)
- [Commits](evanw/esbuild@v0.18.13...v0.18.14)

---
updated-dependencies:
- dependency-name: esbuild
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot requested a review from a team as a code owner July 18, 2023 09:03
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript code labels Jul 18, 2023
@github-actions
github-actions Bot enabled auto-merge July 18, 2023 09:03
@github-actions
github-actions Bot merged commit 2a85d85 into main Jul 18, 2023
@github-actions
github-actions Bot deleted the dependabot/npm_and_yarn/it/typescript/esbuild-0.18.14 branch July 18, 2023 10:00
aqeelat added a commit to aqeelat/kiota that referenced this pull request Jul 15, 2026
Phase 1 of microsoft#7815. Resolves JSON Schema 2020-12 $dynamicRef against
$dynamicAnchor so recursive type hierarchies generate with the active
extending type instead of degrading to UntypedNode.

Resolution delegates to OpenApiWorkspace.ResolveDynamicAnchorInContext
(shipped in OpenAPI.NET 3.9.0 via microsoft/OpenAPI.NET#2913 and microsoft#2945),
addressing the review feedback on microsoft#7817 to move the resolution logic
into the library's reference-resolution path rather than consumer-side
helpers.

KiotaBuilder keeps only a thread-local entry-point frame (the outermost
schema being materialized) to supply as resolution context for the
multi-candidate case, where the library's Target returns null because
more than one schema declares the same $dynamicAnchor.

- Bumps Microsoft.OpenApi / Microsoft.OpenApi.YamlReader to 3.9.0.
- Extends IsSemanticallyMeaningful to treat $dynamicRef schemas as
  meaningful so array dispatch reaches the resolver.
- Logs a warning when a $dynamicRef cannot be resolved instead of
  silently producing UntypedNode.

Known limitation: when a base type declaring $dynamicAnchor is
materialized standalone before any derived type (e.g. it is the
response of another endpoint), dynamic-ref-typed properties resolve
against the base instead of the derived type. The fallback is
UntypedNode with a build-time warning. The fully correct fix is to
emit a union over all candidate derived types -- tracked as Phase 3
in microsoft#7815.

Verified across C#, TypeScript, Go, Python, and Java via the new
parameterized integration test ResolvesRecursiveDynamicRefAsync; all
existing unit tests pass.
aqeelat added a commit to aqeelat/kiota that referenced this pull request Jul 16, 2026
Phase 1 of microsoft#7815. Resolves JSON Schema 2020-12 $dynamicRef against
$dynamicAnchor so recursive type hierarchies generate with the active
extending type instead of degrading to UntypedNode.

Resolution delegates to OpenApiWorkspace.ResolveDynamicAnchorInContext
(shipped in OpenAPI.NET 3.9.0 via microsoft/OpenAPI.NET#2913 and microsoft#2945),
addressing the review feedback on microsoft#7817 to move the resolution logic
into the library's reference-resolution path rather than consumer-side
helpers.

KiotaBuilder keeps only a thread-local entry-point frame (the outermost
schema being materialized) to supply as resolution context for the
multi-candidate case, where the library's Target returns null because
more than one schema declares the same $dynamicAnchor.

- Bumps Microsoft.OpenApi / Microsoft.OpenApi.YamlReader to 3.9.0.
- Extends IsSemanticallyMeaningful to treat $dynamicRef schemas as
  meaningful so array dispatch reaches the resolver.
- Logs a warning when a $dynamicRef cannot be resolved instead of
  silently producing UntypedNode.

Known limitation: when a base type declaring $dynamicAnchor is
materialized standalone before any derived type (e.g. it is the
response of another endpoint), dynamic-ref-typed properties resolve
against the base instead of the derived type. The fallback is
UntypedNode with a build-time warning. The fully correct fix is to
emit a union over all candidate derived types -- tracked as Phase 3
in microsoft#7815.

Verified across C#, TypeScript, Go, Python, and Java via the new
parameterized integration test ResolvesRecursiveDynamicRefAsync; all
existing unit tests pass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant