Update pnpm to v10.29.3

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
pnpm (source)	10.28.2+sha512.41872f037ad22f7348e3b1debbaf7e867cfd448f2726d9cf74c08f19507c31d2c8e7a11525b983febc2df640b5438dee6023ebb1f84ed43cc2d654d2bc326264 → 10.29.3

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

pnpm/pnpm (pnpm)

v10.29.3

Compare Source

v10.29.2

Compare Source

v10.29.1: pnpm 10.29.1

Compare Source

Minor Changes

• The pnpm dlx / pnpx command now supports the catalog: protocol. Example: pnpm dlx shx@catalog:.
• Support configuring auditLevel in the pnpm-workspace.yaml file #​10540.
• Support bare workspace: protocol without version specifier. It is now treated as workspace:* and resolves to the concrete version during publish #​10436.

Patch Changes

• Fixed pnpm list --json returning incorrect paths when using global virtual store #​10187.

• Fix pnpm store path and pnpm store status using workspace root for path resolution when storeDir is relative #​10290.

• Fixed pnpm run -r failing with "No projects matched the filters" when an empty pnpm-workspace.yaml exists #​10497.

• Fixed a bug where catalogMode: strict would write the literal string "catalog:" to pnpm-workspace.yaml instead of the resolved version specifier when re-adding an existing catalog dependency #​10176.

• Fixed the documentation URL shown in pnpm completion --help to point to the correct page at https://pnpm.io/completion #​10281.

• Skip local file: protocol dependencies during pnpm fetch. This fixes an issue where pnpm fetch would fail in Docker builds when local directory dependencies were not available #​10460.

• Fixed pnpm audit --json to respect the --audit-level setting for both exit code and output filtering #​10540.

• update tar to version 7.5.7 to fix security issue

  Updating the version of dependency tar to 7.5.7 because the previous one have a security vulnerability reported here: CVE-2026-24842

• Fix pnpm audit --fix replacing reference overrides (e.g. $foo) with concrete versions #​10325.

• Fix shamefullyHoist set via updateConfig in .pnpmfile.cjs not being converted to publicHoistPattern #​10271.

• pnpm help should correctly report if the currently running pnpm CLI is bundled with Node.js #​10561.

• Add a warning when the current directory contains the PATH delimiter character. On macOS, folder names containing forward slashes (/) appear as colons (:) at the Unix layer. Since colons are PATH separators in POSIX systems, this breaks PATH injection for node_modules/.bin, causing binaries to not be found when running commands like pnpm exec #​10457.

Platinum Sponsors

Gold Sponsors

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[dbkr]

Seems like this upgrade is somehow causing electron-userland/electron-builder#9394

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[t3chguy]

Blocked on electron-userland/electron-builder#9603

In general, the safest approach is to avoid logging full request objects that may contain secrets. Instead, log only non‑sensitive metadata (HTTP method, hostname, path, timeout, etc.), or ensure that any logging that could include secrets uses a robust redaction mechanism with explicit allow‑listing of fields.

Here, the best minimal fix without changing behavior of HTTP requests is to change doApiRequest’s debug logging so that it does not stringify the entire options object. We can log only a subset of fields that are not sensitive (e.g., method, hostname, path, port, timeout) and omit headers entirely. This avoids the need to rely on safeStringifyJson’s heuristic, and ensures that authentication data coming from process.env can no longer reach the log sink at all.

Concretely, in electron-builder/packages/builder-util-runtime/src/httpExecutor.ts, within HttpExecutor.doApiRequest, replace:

if (debug.enabled) {
  debug(`Request: ${safeStringifyJson(options)}`)
}

with a call that logs a safe subset, for example:

if (debug.enabled) {
  const { method, hostname, path, port, timeout } = options
  debug(
    `Request: ${JSON.stringify(
      { method, hostname, path, port, timeout },
      null,
      2
    )}`
  )
}

This change is limited to the logging and does not affect request execution. No new imports or utilities are needed; we can use JSON.stringify directly and avoid touching safeStringifyJson itself (which may be used elsewhere).

---

In general, the fix is to ensure that logs never contain sensitive information, especially anything derived from secrets or environment configuration. For this case, the problematic sink is the response logging in HttpExecutor.handleResponse. We should avoid logging the full RequestOptions structure there, and instead log only a minimal, non-sensitive subset (status code, method, hostname, and a truncated path), or rely on upstream logging that already covers the request.

The best minimal-impact fix is:

• Leave safeStringifyJson as-is (it’s used in other contexts).
• Change handleResponse so it no longer logs safeStringifyJson(options). Instead, log a short message that includes only:
  • response.statusCode and response.statusMessage
  • options.method
  • options.hostname
  • a possibly truncated options.path (to avoid leaking long query strings that could contain identifiers)
• This keeps the ability to debug HTTP responses while removing the path for sensitive data to reach logs.

Concretely:

• File to edit: electron-builder/packages/builder-util-runtime/src/httpExecutor.ts
• In HttpExecutor.handleResponse, replace:

  if (debug.enabled) {
    debug(`Response: ${response.statusCode} ${response.statusMessage}, request options: ${safeStringifyJson(options)}`)
  }

  with something like:

  if (debug.enabled) {
    const { method, hostname, path } = options
    const safePath = typeof path === "string" && path.length > 200 ? path.substring(0, 200) + "…" : path
    debug(`Response: ${response.statusCode} ${response.statusMessage} (method: ${method || "GET"}, host: ${hostname}, path: ${safePath})`)
  }

• No new imports are needed; we only use basic string operations.

No changes are required in ArtifactPublisherTest.ts or keygenPublisher.ts because the primary risky logging occurs in httpExecutor.ts.

---

To fix the problem in general, the escaping routine should escape both double quotes and backslashes in a consistent way, so that any backslash in the original string cannot accidentally act as an escape for a following meta-character. This means replacing each single backslash with a double backslash, then replacing double quotes with an escaped form, before wrapping the entire string in quotes.

Concretely, in electron-builder/packages/electron-builder/src/cli/create-self-signed-cert.ts, we should update quoteString so it first escapes backslashes and then escapes double quotes. The function’s logic determining whether quoting is needed (if (!s.includes(",") && !s.includes('"'))) remains unchanged to preserve current behavior for simple names. Only the return statement should be adjusted so that s is transformed by both s.replace(/\\/g, "\\\\") and s.replace(/"/g, '\\"'), for example by chaining the replace calls. No additional imports or helpers are required.

In general, instead of checking url.includes("host"), parse the URL and only check the hostname (or host) field so that hostPattern cannot be matched from the path/query/fragment or from unrelated hostnames. This avoids false positives where "s3.amazonaws.com" appears outside the actual host.

For this specific case, we should replace the substring check in isUrlProbablySupportMultiRangeRequests with logic that parses the URL and inspects the hostname. Using Node’s standard URL class is sufficient and does not require new dependencies. We should treat any URL whose hostname is exactly s3.amazonaws.com or ends with .s3.amazonaws.com as S3-like, and return false in that case; for all other hosts (or unparsable URLs) we keep the previous default behavior (true, meaning "probably supports multi-range requests"). To maintain robustness, wrap URL parsing in a try/catch and fall back to true (i.e., do not disable multi-range) if parsing fails.

Concretely in electron-builder/packages/electron-updater/src/providerFactory.ts:

• Update isUrlProbablySupportMultiRangeRequests to:
  • Attempt new URL(url) and get hostname.
  • If hostname === "s3.amazonaws.com" or hostname.endsWith(".s3.amazonaws.com"), return false.
  • Otherwise return true.
• No other code needs modification, and no new imports are required because URL is globally available in modern Node/Electron environments.