Skip to content

Bump esbuild from 0.28.0 to 0.28.1 - #1

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/esbuild-0.28.1
Open

Bump esbuild from 0.28.0 to 0.28.1#1
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/esbuild-0.28.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jun 12, 2026

Copy link
Copy Markdown

Bumps esbuild from 0.28.0 to 0.28.1.

Release notes

Sourced from esbuild's releases.

v0.28.1

  • Disallow \ in local development server HTTP requests (GHSA-g7r4-m6w7-qqqr)

    This release fixes a security issue where HTTP requests to esbuild's local development server could traverse outside of the serve directory on Windows using a \ backslash character. It happened due to the use of Go's path.Clean() function, which only handles Unix-style / characters. HTTP requests with paths containing \ are no longer allowed.

    Thanks to @​dellalibera for reporting this issue.

  • Add integrity checks to the Deno API (GHSA-gv7w-rqvm-qjhr)

    The previous release of esbuild added integrity checks to esbuild's npm install script. This release also adds integrity checks to esbuild's Deno install script. Now esbuild's Deno API will also fail with an error if the downloaded esbuild binary contains something other than the expected content.

    Note that esbuild's Deno API installs from registry.npmjs.org by default, but allows the NPM_CONFIG_REGISTRY environment variable to override this with a custom package registry. This change means that the esbuild executable served by NPM_CONFIG_REGISTRY must now match the expected content.

    Thanks to @​sondt99 for reporting this issue.

  • Avoid inlining using and await using declarations (#4482)

    Previously esbuild's minifier sometimes incorrectly inlined using and await using declarations into subsequent uses of that declaration, which then fails to dispose of the resource correctly. This bug happened because inlining was done for let and const declarations by avoiding doing it for var declarations, which no longer worked when more declaration types were added. Here's an example:

    // Original code
    {
      using x = new Resource()
      x.activate()
    }
    // Old output (with --minify)
    new Resource().activate();
    // New output (with --minify)
    {using e=new Resource;e.activate()}

  • Fix module evaluation when an error is thrown (#4461, #4467)

    If an error is thrown during module evaluation, esbuild previously didn't preserve the state of the module for subsequent module references. This was observable if import() or require() is used to import a module multiple times. The thrown error is supposed to be thrown by every call to import() or require(), not just the first. With this release, esbuild will now throw the same error every time you call import() or require() on a module that throws during its evaluation.

  • Fix some edge cases around the new operator (#4477)

    Previously esbuild incorrectly printed certain edge cases involving complex expressions inside the target of a new expression (specifically an optional chain and/or a tagged template literal). The generated code for the new target was not correctly wrapped with parentheses, and either contained a syntax error or had different semantics. These edge cases have been fixed so that they now correctly wrap the new target in parentheses. Here is an example of some affected code:

    // Original code
    new (foo()`bar`)()
    new (foo()?.bar)()
    // Old output
    new foo()bar();
    new (foo())?.bar();

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.28.1

  • Disallow \ in local development server HTTP requests (GHSA-g7r4-m6w7-qqqr)

    This release fixes a security issue where HTTP requests to esbuild's local development server could traverse outside of the serve directory on Windows using a \ backslash character. It happened due to the use of Go's path.Clean() function, which only handles Unix-style / characters. HTTP requests with paths containing \ are no longer allowed.

    Thanks to @​dellalibera for reporting this issue.

  • Add integrity checks to the Deno API (GHSA-gv7w-rqvm-qjhr)

    The previous release of esbuild added integrity checks to esbuild's npm install script. This release also adds integrity checks to esbuild's Deno install script. Now esbuild's Deno API will also fail with an error if the downloaded esbuild binary contains something other than the expected content.

    Note that esbuild's Deno API installs from registry.npmjs.org by default, but allows the NPM_CONFIG_REGISTRY environment variable to override this with a custom package registry. This change means that the esbuild executable served by NPM_CONFIG_REGISTRY must now match the expected content.

    Thanks to @​sondt99 for reporting this issue.

  • Avoid inlining using and await using declarations (#4482)

    Previously esbuild's minifier sometimes incorrectly inlined using and await using declarations into subsequent uses of that declaration, which then fails to dispose of the resource correctly. This bug happened because inlining was done for let and const declarations by avoiding doing it for var declarations, which no longer worked when more declaration types were added. Here's an example:

    // Original code
    {
      using x = new Resource()
      x.activate()
    }
    // Old output (with --minify)
    new Resource().activate();
    // New output (with --minify)
    {using e=new Resource;e.activate()}

  • Fix module evaluation when an error is thrown (#4461, #4467)

    If an error is thrown during module evaluation, esbuild previously didn't preserve the state of the module for subsequent module references. This was observable if import() or require() is used to import a module multiple times. The thrown error is supposed to be thrown by every call to import() or require(), not just the first. With this release, esbuild will now throw the same error every time you call import() or require() on a module that throws during its evaluation.

  • Fix some edge cases around the new operator (#4477)

    Previously esbuild incorrectly printed certain edge cases involving complex expressions inside the target of a new expression (specifically an optional chain and/or a tagged template literal). The generated code for the new target was not correctly wrapped with parentheses, and either contained a syntax error or had different semantics. These edge cases have been fixed so that they now correctly wrap the new target in parentheses. Here is an example of some affected code:

    // Original code
    new (foo()`bar`)()
    new (foo()?.bar)()
    // Old output
    new foo()bar();
    new (foo())?.bar();

... (truncated)

Commits

Dependabot compatibility score

You can trigger a rebase of this PR 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 show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @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)
    You can disable automated security fix PRs for this repo from the Security Alerts page.

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

Bumps [esbuild](https://github.com/evanw/esbuild) from 0.28.0 to 0.28.1.
- [Release notes](https://github.com/evanw/esbuild/releases)
- [Changelog](https://github.com/evanw/esbuild/blob/main/CHANGELOG.md)
- [Commits](evanw/esbuild@v0.28.0...v0.28.1)

---
updated-dependencies:
- dependency-name: esbuild
  dependency-version: 0.28.1
  dependency-type: direct:development
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code labels Jun 12, 2026
jaredmoody pushed a commit that referenced this pull request Sep 4, 2026
…arcoroth#2528)

This pull request updates the dev server to notice templates that were
already broken before it started, and to tell browsers about them when
they connect.

Indexing read every template but never parsed one, so `broken_files`
started empty and nothing downstream knew a template was broken until
someone touched it. Two things followed from that, and a third fell out
of fixing them.

#### Repairing a template the server indexed as broken

Because the template was never recorded as broken, repairing it missed
the recovery path entirely and fell through to the diff. The diff was
computed against a previous source that does not parse, so the
operations were meaningless:

**Before**

```
    17:14:32.245 ↻ fetch   app/views/posts/index.html.erb (2 operations)
                        #1 node removed [0, 1]
                          - HTML_OPEN_TAG (2:2)
                        #2 node inserted [0, 1]
                          + <form>
```

**After**

```
    17:18:45.909 ✓ clear   app/views/posts/index.html.erb
```

`Watcher#index` now parses what it reads and records the templates that
fail, the runner seeds its own set from that, and
`Pipeline#remember_broken` marks them `:parse_error` so the clearing
schema reaches browsers. Both entry points are wired, the CLI runner and
the embedded boot in `Herb::Dev.boot`. Recovery also no longer prints a
diff summary, since there is nothing meaningful to diff against.

Parsing every template at startup costs about 45ms for 1000 templates,
measured against the read that was already happening.

#### Saying so at startup

Now that indexing knows, the header says it:

```
  Files:     453 templates indexed, 3 don't parse
  Files:     1 template indexed, 1 doesn't parse
```

The count goes through the existing `pluralize` helper, which also fixes
`1 templates indexed`.

#### Telling browsers on connect

A browser that connects after the server started had no way to learn any
of this. `Protocol.welcome` now carries the list, which is the one frame
every browser receives regardless of when it shows up:

```json
{
  "type": "welcome",
  "project": "/Users/marcoroth/Development/demos/reactionview-demo",
  "broken_files": [
    "app/views/posts/index.html.erb",
    "app/views/posts/second.html.erb"
  ]
}
```

`Server#on_welcome` takes a block the server calls per connection rather
than a payload baked at startup, so a browser connecting after you
repair something gets the shorter list. The client reports each one into
the existing diagnostic sink, so they render as ordinary overlay cards:

Follow up on marcoroth#2468 and marcoroth#2469.
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.

0 participants