Repository navigation
chore: clear 39 open Dependabot alerts via pnpm update - #180
Merged
Merged
Conversation
All resolved within existing semver ranges via pnpm update -r — no direct dependency needed a major-version bump. Most alerts traced back to two chains: @modelcontextprotocol/sdk (packages/mcp, a published runtime dep) pulling hono/express/undici/etc., and @vscode/vsce (packages/vscode, dev-only VSIX packaging) pulling cheerio/js-yaml/typed-rest-client. A Linux-only glib alert (transitive via tauri's GTK stack) is not yet actionable, no newer version is reachable within the current dependency graph.
devlint
pushed a commit
that referenced
this pull request
Sep 9, 2026
The Bundle smoke build job has failed on every main push since #180. `pnpm update -r` bumped the npm half of two Tauri plugins without the Rust half, and `tauri build` refuses to run on a major/minor mismatch: tauri-plugin-notification 2.3.3 vs @tauri-apps/... 2.4.0 tauri-plugin-updater 2.10.1 vs @tauri-apps/... 2.11.0 Lock the Rust crates to 2.4.0 and 2.11.0. Cargo.toml already declared "2", so only Cargo.lock moves; no version file is edited by hand. The job is gated on `Detect bundle-relevant changes` and reports `skipping` on pull requests, so six days of red main builds sat behind green PR checks. Verified: cargo test --lib 260/260, cargo check --features telemetry (the flags CI builds with) clean, and `tauri info` now reports 2.4.0 and 2.11.0 matching on both sides.
devlint
pushed a commit
that referenced
this pull request
Sep 9, 2026
The #180 entry said no newer glib was "reachable within the current tauri/tao/gtk-rs dependency graph". Half of that is now out of date: gtk-rs shipped the fix. glib 0.22 is out and gtk 0.19 landed with it on 2026-09-08, after gtk3-rs picked up a new maintainer who merged the 0.22 bump (gtk-rs/gtk3-rs#857). What has not moved is tao: 0.37.0 still requires gtk ^0.18, which pins glib to 0.18.x. So the conclusion is unchanged, no cargo update reaches the fix, but the blocker is now one version requirement rather than the whole gtk-rs side. Note also that tauri#12564 was closed as not planned in favour of a gtk4-rs migration, so the gtk3-rs work is independent of Tauri's own plan. Tracked upstream at tauri-apps/tao#1281.
This was referenced Sep 10, 2026
devlint
added a commit
that referenced
this pull request
Sep 10, 2026
* fix(dev-server): reject non-UTF-8 files like Rust does, and pin it (#188 pt2) Rust's `read_file` is `std::fs::read_to_string`, which rejects a file that is not valid UTF-8. The dev-server called `readFileSync(path, "utf-8")`, which substitutes U+FFFD and succeeds. Both "worked", so no test caught it, and the gap was not cosmetic: a non-UTF-8 file among a repository's conflicts made *every* conflict unresolvable in the packaged app (fixed in #187), while the same repository loaded fine under `pnpm dev:web`. Manual QA on that exact path came back green. - dev-server reads bytes and decodes with `TextDecoder(fatal: true)`, returning Rust's error string verbatim so the two fail identically. - `backend.ts#readFile` surfaces the server's reason instead of a generic message; callers and the parity suite need the failure text. - `read_file_parity` + a `read-file` arm on the probe. - `tests/parity/read-file.test.mjs`, 5 cases. Unlike every other parity test, which compares two successes, these assert both backends REFUSE the same input for the same stated reason. Also covers the missing file and the path-traversal refusal. Watched failing first: reverting the dev-server to `readFileSync(utf-8)` turns two of the five red with "node unexpectedly accepted a non-UTF-8 file", which is exactly the drift that shipped. Audited `read_file_at_revision` for the same shape: it returns base64 bytes and never decodes, so no divergence is possible there. * ci: run bundle-smoke on same-repo PRs, not only on push to main (#188 pt1) `Bundle smoke build` is the only job that executes `tauri build`, so it is the only one that catches bundler-level breakage. It was gated to push-to-main and reported `skipping` on every PR, which means a PR could be legitimately all-green and still break `main` on merge. That is not hypothetical. #180 bumped the npm half of two Tauri plugins without the Rust half; `tauri build` refuses a major/minor mismatch, and `main` stayed red from 2026-09-03 to 2026-09-09 behind green PR checks, noticed only because someone opened the Actions tab. The PR filter is deliberately narrower than the push one: only `apps/desktop/src-tauri`, `pnpm-lock.yaml`, `apps/desktop/package.json` and `ci.yml` itself. Those are what can break the bundler, and they are worth ~13 min; a frontend-only PR stays covered by the push-to-main run rather than taxing every PR. Fork PRs are excluded on purpose: the job signs with TAURI_SIGNING_PRIVATE_KEY and secrets are not exposed to forks, so it could only ever fail there. Verified the filter both ways by running its script against real commits: `true` for the previous commit (touches src-tauri), `false` for 374145e (changelog only). A filter that cannot say no is not a filter. * ci(release): assert the update manifest is actually live (#188 pt4) `actions/deploy-pages@v4` reporting success does not mean the site changed. Pages deduplicates by `pages_build_version`, which is the commit sha, and a release tag points at the same commit `Deploy Website` already deployed on push to main. Pages then creates no deployment, prints "Reported success!", and keeps serving the old content. Every step shows a checkmark. v3.10.1 shipped that way: 14 complete artifacts, npm published, Homebrew bumped, and https://gitwand.app/update/latest.json still advertising 3.10.0. Nobody would have been offered the update. It was caught by fetching the live URL by hand, not by CI. The job now fetches that URL after deploying and fails unless it serves the version just built, retrying for 6 minutes because Pages' CDN caches for 600s and ignores query strings. On failure it names the likely cause and the remedy (manual `workflow_dispatch` on Deploy Website), which is what actually unblocked it. This is the issue's general rule applied to the worst offender: a step that reports success must have an observable effect, and the pipeline should assert the effect rather than trust the status. Checked both directions against the live endpoint: passes for 3.10.1, fails with a readable message when told to expect 3.10.2. Not done here: having the release auto-trigger Deploy Website on mismatch. That needs `actions: write` on the release workflow's token, which is a permission escalation worth deciding separately. A loud, actionable failure is the honest minimum. * style: rustfmt the parity probe import list * docs(changelog): record the #188 pipeline fixes * docs(roadmap): the read-file parity item is done, generalise what remains Filed yesterday as a v3.11.0 follow-up; #189 fixes it and audits read_file_at_revision clean. What is left is the general question it exposed: parity coverage compares happy paths almost everywhere, so other routes may agree on success while disagreeing on failure. --------- Co-authored-by: Laurent Guitton <laurent.guitton@dendreo.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
pnpm update -racross the monorepo, resolving all 39 open Dependabot alerts (high/medium/low) entirely within existing semver ranges — no direct dependency needed a major-version bump.@modelcontextprotocol/sdk(packages/mcp, a published runtime dependency of@gitwand/mcp): pullshono,@hono/node-server,express,express-rate-limit,body-parser,qs,ip-address,ajv/ajv-formats,undici,fast-uri. Bumped^1.12.1→^1.30.0.@vscode/vsce(packages/vscode, dev-only VSIX packaging tool — never shipped): pullscheerio,@textlint/linter-formatter→js-yaml,azure-devops-node-api→typed-rest-client. Bumped^3.0.0→^3.9.2.glibalert (transitive viatauri's GTK stack:tauri→tao/gtk→atk/glib) is not actionable yet —cargo update -p glib --dry-runconfirms no newer version is reachable within the current dependency graph. Tracked for the nexttaurirelease.Verification
pnpm test— all 5 workspaces green (68+122+11+2+2 test files, 0 failures)pnpm build— clean, all workspacesfirst_patched_versionpnpm peers check— one pre-existing@xterm/xtermpeer mismatch, unrelated to this change (its^6.0.0range predates this PR; not introduced here)Test plan