Skip to content

Bump vite from 4.4.4 to 6.4.2 in /cmd/relay/relay-admin-ui#1382

Open
dependabot[bot] wants to merge 4309 commits into
mainfrom
dependabot/npm_and_yarn/cmd/relay/relay-admin-ui/vite-6.4.2
Open

Bump vite from 4.4.4 to 6.4.2 in /cmd/relay/relay-admin-ui#1382
dependabot[bot] wants to merge 4309 commits into
mainfrom
dependabot/npm_and_yarn/cmd/relay/relay-admin-ui/vite-6.4.2

Conversation

@dependabot

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

Copy link
Copy Markdown

Bumps vite from 4.4.4 to 6.4.2.

Release notes

Sourced from vite's releases.

v6.4.2

Please refer to CHANGELOG.md for details.

v6.4.1

Please refer to CHANGELOG.md for details.

v6.4.0

Please refer to CHANGELOG.md for details.

v6.3.7

Please refer to CHANGELOG.md for details.

v6.3.6

Please refer to CHANGELOG.md for details.

v5.4.21

Please refer to CHANGELOG.md for details.

v5.4.20

Please refer to CHANGELOG.md for details.

Changelog

Sourced from vite's changelog.

6.4.2 (2026-04-06)

6.4.1 (2025-10-20)

6.4.0 (2025-10-15)

  • feat: allow passing down resolved config to vite's createServer (#20932) (ca6455e), closes #20932

6.3.7 (2025-10-14)

  • fix(esbuild): inject esbuild helpers correctly for esbuild 0.25.9+ (#20940) (c59a222), closes #20940

6.3.6 (2025-09-08)

6.3.5 (2025-05-05)

6.3.4 (2025-04-30)

  • fix: check static serve file inside sirv (#19965) (c22c43d), closes #19965
  • fix(optimizer): return plain object when using require to import externals in optimized dependenci (efc5eab), closes #19940
  • refactor: remove duplicate plugin context type (#19935) (d6d01c2), closes #19935

6.3.3 (2025-04-24)

... (truncated)

Commits
Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for vite since your current version.


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 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.

dholms and others added 30 commits December 18, 2025 14:51
One might need custom plc directory endpoint other than
<https://plc.directory> for testing purposes or for plc mirrors.

As tap supports full network backfill, it would be better to test that
on sandboxed atproto infra than public infra with ~40M repos.

So I added a `plc-url` flag and `TAP_PLC_URL` env var.
Same as relay, `ATP_PLC_HOST` env var can also be used instead.
As indicated in the comment, adding an actual foreign key relationship
would probably help with this. But doing it as a query tweak is a
simpler change to deploy (no schema change).
Seeing lots of crashes in rainbow due to us sending to `s.outgoing` even
though it's already been closed.

This is clearly a bandaid, but we need a fix ASAP, and this should
probably be in there anyways

<img width="1608" height="823" alt="image"
src="https://github.com/user-attachments/assets/ce0ba2d3-b9a4-4564-9de9-3b69070ef67b"
/>

^ note that large recent missing data blip was me cutting the rainbow
process over to a new management system. Had a bit of downtime (sorry!)
Resyncer was setting `retry_after` but then not actually respecting it
when claiming a job

Closes #1239
We were verifying structure of commit, but not verifying the signature
itself.

Closes #1238
Follow up to #1247

Ensure we're retrying errored repos and increase backoff to 1-60min as
opposed to 1-60s
…rrors (#1257)

When Tap restarts, the EventManager loads existing events from the
database but doesn't initialize the nextID counter. This causes new
events to be assigned IDs starting from 0, which collide with existing
database records.

The fix restores the nextID counter as events are loaded, ensuring new
IDs are always greater than any existing database IDs.

Fixes #1253
This reverts commit 2c00289.


We need to remove this field here and from `@atproto/bsky`, deploy the
lexicon without it, and then re-add it as string.

Long story short: `recId` is an `int64` and TS/JS cannot get the machine
ID out of it because it can't handle big integers unless with explicity
`BigInt` — which is not the case in our stack. So we're gonna pass it
ias string instead.

Related PRs:

* bluesky-social/atproto#4440
* #1263
* bluesky-social/seeemore#155 
* bluesky-social/seeemore#158
github.com/bluesky-social/indigo/api/atproto was imported twice, the second time
under an alias. This commit removes the duplicated import.
github.com/bluesky-social/indigo/api/atproto was imported twice, the
second time under an alias. This commit removes the duplicated import.
bnewbold and others added 25 commits April 8, 2026 13:38
(this is on top of the Go v1.26 PR; we should merge that first)

An initial batch of `go fix ./...` changes. We are likely to want to
merge in more auto-fixes, but this is a broad start for things like
for/range, `interface{}` to `any`, `wg.Go()`, etc. I manually skimmed
all of these and they seem safe.
Simply updates to Go v1.26.

Have a follow-up PR with some `go fix ./...` updates.

Most of our go repos which depend on indigo have already been updated,
but I have separate PRs out for some straglers.
This fixes two dropped `err` variables in `atproto/auth`. I tried to
follow the most canonical use of `%w` in a `fmt.Errorf`. If this project
follows a different standard, I'll happily change it.

Unit tests passed both before and after changes.
This picks up a dropped test error in `lex/util`.
The motivation is that we are looking at doing a "gallery" embed type on
bsky posts, and want to constrain the increase in concurrent goroutines.
In particular, the number of concurrent HTTP requests being made by
automod to PDS instances to download the blobs: we don't want automod to
get rate-limited if it is doing dozens of concurrent blob requests to a
small/simple PDS due to a single record; or to DDoS that type of PDS
instance if it does not have limits on concurrent requests in place.

Note that this patch does *not* add concurrency limits on processing
rules for individual blobs. If an automod process had 20 blob rules, and
concurrent blob processing of 8x, it might start 160 processing
goroutines at the same time. This is expected to be fine because blob
rules are usually "per service", and these requests would be going to
separate backend services. The best way to constrain concurrency there
is to limit the overall number of worker queues.

Note that i'm not using `errgroup.WithContext` (doesn't seem needed),
and that i'm doing the old-fashioned `blob := blob` variable
re-assignment in the for-loops out of habit, even though loop vars were
fixed in Go 1.22.

Mostly requesting review from Rafael, but also tagging Jim for review
(if he has time) just for idiomatic Go concurrency patterns.
In this new version of the relay, only the account limit is actually
editable. This clarifies this by making the other event limits static
(not editable)
Adds a **non-breaking change** to `backfill` package.

* With `.Start()` it would use the default logger
* This PR adds `StartWithLogger(*slog.Logger)` so the user can use a
custom logger
* Now `Start()` just wraps the default logger in a `StartWithLogger`
call (so, not breaking the API)

(the two other minor changes are from the linter)
Motivation is to make it clearer how to operate the relay, eg when
bumping limits. Only the account limit is actually editable.

Also a small patch to improve logging/printing at startup (uses slog
instead of 'echo' web framework default port printing).
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 4.4.4 to 6.4.2.
- [Release notes](https://github.com/vitejs/vite/releases)
- [Changelog](https://github.com/vitejs/vite/blob/v6.4.2/packages/vite/CHANGELOG.md)
- [Commits](https://github.com/vitejs/vite/commits/v6.4.2/packages/vite)

---
updated-dependencies:
- dependency-name: vite
  dependency-version: 6.4.2
  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 May 12, 2026
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.