Dashboard › spotlight › Session 0aIL3Z97YC8p
0aIL3Z97YC8pmYEGYYou are performing an ADVERSARIAL, EVIDENCE-BASED CORRECTNESS review of two PRs in getsentry/spotlight. Be skeptical. Trace every claim to actual evidence (lockfile, source code, registry metadata). Do NOT surface style/cosmetics — CORRECTNESS only.
Both PRs close Dependabot alerts in pnpm-lock.yaml via pnpm overrides and direct dep bumps.
security/deps-2026-07-28 (branch: security/deps-2026-07-28, base: main)chore(deps): remediate 22 Dependabot alerts via pnpm overridesfix/astro-7-vite-8-migration (branch: fix/astro-7-vite-8-migration, base: main)chore(deps): migrate Astro 6 -> 7 + Vite 8 (closes #301 #302)Repo info:
packages/spotlight, packages/website, root package.json with pnpm.overrides, pnpm-workspace.yaml catalog, pnpm-lock.yamlsecurity/deps-2026-07-28 and fix/astro-7-vite-8-migration exist but have uncommitted/unmerged conflicts that will be re-applied to origin/main stateSeer already posted two CRITICAL inline comments on PR #1341 (treat as MUST-VERIFY, not as ground truth):
package.json:57 — "@xmldom/xmldom": ">=0.8.13" is open-ended → resolves to 0.9.10 which broke plist@3.1.0 → DOMParser.parseFromString requiring mimeType. Suggested fix: add <0.9 ceiling.package.json:47 — "brace-expansion": ">=2.1.0 <3" blanket breaks app-builder-lib@26.15.7 → minimatch@10 → brace-expansion@^5 for macOS build. Suggested fix: per-major ranges like "brace-expansion@<2.0.0": ">=1.1.12 <2", etc.For EACH PR, produce a numbered adversarial review covering these points. Include severity (CRITICAL/HIGH/MEDIUM/LOW) and CONCRETE EVIDENCE per finding.
Let me start by gathering the necessary information for this adversarial review. I need to:
Let me start by running these in parallel where possible.
I'll perform an adversarial, evidence-based correctness review of both PRs. Let me start by gathering the necessary data.
{"additions":397,"baseRefOid":"7bba9f962d6a8ba935a8d2e04faa3d07ec5f1742","deletions":710,"files":[{"path":".lore.md","additions":79,"deletions":7,"changeType":"MODIFIED"},{"path":"package.json","additions":12,"deletions":6,"changeType":"MODIFIED"},{"path":"packages/spotlight/package.json","additions":2,"deletions":2,"changeType":"MODIFIED"},{"path":"pnpm-lock.yaml","additions":304,"deletions":695,"changeType":"MODIFIED"}],"headRefOid":"50016108d56cbf3ff88e51b2d11e4273212e7e1b","state":"OPEN","title":"chore(deps): remediate 22 Dependabot alerts via pnpm overrides"}
{"additions":1250,"baseRefOid":"7bba9f962d6a8ba935a8d2e04faa3d07ec5f1742","deletions":1564,"files":[{"path":".lore.md","additions":79,"deletions":7,"changeType":"MODIFIED"},{"path":"package.json","additions":13,"deletions":8,"changeType":"MODIFIED"},{"path":"packages/spotlight/package.json","additions":4,"deletions":4,"changeType":"MODIFIED"},{"path":"packages/spotlight/src/svg.d.ts","additions":27,"deletions":0,"changeType":"ADDED"},{"path":"packages/spotlight/vite.config.base.ts","additions":3,"deletions":0,"changeType":"MODIFIED"},{"path":"packages/website/astro.config.mjs","additions":1,"deletions":8,"changeType":"MODIFIED"},{"path":"packages/website/package.json","additions":5,"deletions":6,"changeType":"MODIFIED"},{"path":"pnpm-lock.yaml","additions":1116,"deletions":1529,"changeType":"MODIFIED"},{"path":"pnpm-workspace.yaml","additions":2,"deletions":2,"changeType":"MODIFIED"}],"headRefOid":"021ac8ec4eb2d1e3c9539fb0d4a39e3f2b7c77eb","state":"OPEN","title":"chore(deps): migrate ...
...output truncated... Full output saved to: /home/byk/.local/share/opencode/tool-output/tool_fa8b04829001rG20UuGIE6Q7dN replace()` loop forever while scanning the existing archive. Applications that update attacker-controlled tar archives can have a worker process pinned indefinitely, causing denial of service.\n\n### Details\n\nThe public `tar.replace()` API scans the existing archive before appending replacement entries. During this scan, it parses each tar header and advances the archive position by the parsed entry size rounded to a 512-byte block boundary.\n\nTar supports base-256 encoded numeric fields. A crafted header can encode the entry size as `-512` while still carrying a valid checksum. The replace scan accepts that parsed negative size and uses it in the position-advance calculation.\n\nFor a size of `-512`, the computed body skip is `-512`. The scan then adds the normal 512-byte header step, resulting in no net progress. ...
Let me read the full alerts output and PR data. I need to get the complete list of open alerts first, then examine the PRs.
Traceback (most recent call last): File "<string>", line 12, in <module> KeyError: 'vulnerable_version_range' Total open alerts: 28
From https://github.com/getsentry/spotlight * branch security/deps-2026-07-28 -> FETCH_HEAD * branch fix/astro-7-vite-8-migration -> FETCH_HEAD
From https://github.com/getsentry/spotlight * branch main -> FETCH_HEAD
Let me fix the alert parsing and extract all alerts.
Total open alerts: 28 #323 [high ] brace-expansion transitive range=<= 5.0.7 patched=5.0.8 manifest=pnpm-lock.yaml #322 [high ] react-router transitive range=>= 7.12.0, < 8.3.0 patched=8.3.0 manifest=pnpm-lock.yaml #321 [medium ] tar transitive range=<= 7.5.20 patched=7.5.21 manifest=pnpm-lock.yaml #320 [high ] postcss transitive range=<= 8.5.17 patched=8.5.18 manifest=pnpm-lock.yaml #319 [high ] react-router transitive range=>= 7.0.0, < 7.18.0 patched=7.18.0 manifest=pnpm-lock.yaml #318 [high ] builder-util-runtime transitive range=< 9.7.0 patched=9.7.0 manifest=pnpm-lock.yaml #317 [high ] app-builder-lib ...
Now let me understand the alerts:
28 total open alerts. Note the seriated numbering does not match the ones the user mentioned (301, 302) — but I see them. Let me track the major categories:
Critical/High alerts to focus on:
Got the alert data. Now let me dig into the actual PR contents and lockfile resolutions.
021ac8ec4eb2d1e3c9539fb0d4a39e3f2b7c77eb
diff --git a/.lore.md b/.lore.md
index 0f667984..889b5eba 100644
--- a/.lore.md
+++ b/.lore.md
@@ -5,12 +5,30 @@
### Decision
<!-- lore:019e2add-e248-7c69-81d6-55de39182966 -->
-* **Migrated to Content Layer API**: Migrated to Content Layer API in getsentry/spotlight. \`packages/website/content.config.ts\` is an untracked file that should NOT be committed in security/dependency bump PRs — it is intentionally excluded from those commits.
+* **Two content.config.ts files in spotlight website — canonical vs legacy**: Two content.config.ts files exist in getsentry/spotlight: packages/website/src/content.config.ts (TRACKED, canonical, uses Content Layer API via \`docsLoader\`/\`i18nLoader\` from @astrojs/starlight/loaders + docsSchema/i18nSchema) and packages/website/content.config.ts (UNTRACKED, legacy, uses old \`defineCollection({ type: 'content', schema: docsSchema() })\` and \`type: 'data'\` API — NO loaders). Astro prefers src/content.config.ts per Content Layer convention; the ...
diff --git a/.lore.md b/.lore.md
index 0f667984..889b5eba 100644
--- a/.lore.md
+++ b/.lore.md
@@ -5,12 +5,30 @@
### Decision
<!-- lore:019e2add-e248-7c69-81d6-55de39182966 -->
-* **Migrated to Content Layer API**: Migrated to Content Layer API in getsentry/spotlight. \`packages/website/content.config.ts\` is an untracked file that should NOT be committed in security/dependency bump PRs — it is intentionally excluded from those commits.
+* **Two content.config.ts files in spotlight website — canonical vs legacy**: Two content.config.ts files exist in getsentry/spotlight: packages/website/src/content.config.ts (TRACKED, canonical, uses Content Layer API via \`docsLoader\`/\`i18nLoader\` from @astrojs/starlight/loaders + docsSchema/i18nSchema) and packages/website/content.config.ts (UNTRACKED, legacy, uses old \`defineCollection({ type: 'content', schema: docsSchema() })\` and \`type: 'data'\` API — NO loaders). Astro prefers src/content.config.ts per Content Layer convention; the ...
Now I have crucial information. Let me analyze what I'm seeing in PR #1341:
PR #1341 (security/deps-2026-07-28) — package.json change summary:
REMOVED:
"vite@>=6.0.0 <6.4.2": "~6.4.2" (kept)"vite@>=7.0.0 <7.3.5": ">=7.3.5 <8" ← REMOVED (loosening vite ceiling)"brace-expansion": ">=2.1.0 <3""js-yaml": ">=4.2.0 <5" ← tightened to ">=4.3.0 <5""body-parser": ">=2.2.1" ← tightened to ">=2.3.0""fast-uri": ">=3.1.2" ← tightened to ">=3.1.4""postcss": ">=8.5.10" ← tightened to ">=8.5.18""shell-quote": ">=1.8.4" ← tightened to ">=1.9.0""@xmldom/xmldom": ">=0.8.13 <0.9" ← back to OPEN-ENDED ">=0.8.13" (HEAD WITHOUT CEILING)ADDED:
"brace-expansion": ">=2.1.0 <3" (single blanket)"glob@>=13.0.0": "10.4.5" (locks glob back to v10 so its minimatch@^10 doesn't pull brace-expansion@5.x)"@hono/node-server": ">=2.0.5""sharp": ">=0.35.0"Now I have a comprehensive view. Let me inspect the actual lockfile resolutions and check critical details.
lockfileVersion: 9.0 Total packages: 1549
Hmm, the output got cut off, possibly because yaml.safe_load with non-yaml-printable output got truncated. Let me try a different approach.
14848 /tmp/opencode/lock1341.yaml
14826 /tmp/opencode/lock1342.yaml
15408 /tmp/opencode/lockmain.yaml
Let me extract key package versions from each lockfile.
=== /tmp/opencode/lockmain.yaml === === /tmp/opencode/lock1341.yaml === === /tmp/opencode/lock1342.yaml ===
The output seems truncated. Let me try with a simpler approach.
=== MAIN === === PR1341 === === PR1342 ===
Strange — the output was suppressed. Let me try without redirection.
=== MAIN === package_count=1606 === PR1341 === package_count=1549 === PR1342 === package_count=1547
OK so yaml.safe_load works. Let me try the targeted version check now — perhaps it's just being slow.
brace-expansion versions: [] glob versions: [] @xmldom/xmldom versions: [] tar versions: [] js-yaml versions: [] minimatch versions: [] vite versions: [] plist versions: [] svgo versions: [] sharp versions: [] app-builder-lib versions: [] builder-util-runtime versions: [] electron-builder versions: [] @hono/node-server versions: [] postcss versions: [] fast-uri versions: [] shell-quote versions: [] body-parser versions: [] react-router-dom versions: []
Hmm, all empty. That means the YAML safe_load isn't actually finding the 'name' field. Let me debug.
'7zip-bin@5.2.0' -> {'resolution': {'integrity': 'sha512-ukTPVhqG4jNzMro2qA9HSCSSVJN3aN7tlb+hfqYCt3ER0yWroeA2VR38MNrOHLQ/cVj+DaIMad0kFCtWWowh/A=='}}
'@adobe/css-tools@4.4.4' -> {'resolution': {'integrity': 'sha512-Elp+iwUx5rN5+Y8xLt5/GRoG20WGoDCQ/1Fb+1LiGtvwbDavuSk0jhD/eZdckHAuzcDzccnkv+rEjyWfRx18gg=='}}
'@ampproject/remapping@2.3.0' -> {'resolution': {'integrity': 'sha512-30iZtAPgz+LTIYoeivqYo853f02jBYSd5uGnGpkFV0M3xOt9aN73erkgYAmZU43x4VfqcnLxW9Kpg3R5LC4YYw=='}, 'engines': {'node': '>=6.0.0'}}
'@antfu/utils@0.7.10' -> {'resolution': {'integrity': 'sha512-+562v9k4aI80m1+VuMHehNJWLOFjBnXn3tdOitzD0il5b7smkSBal4+a3oKiQTbrwMmN/TBUMDvbdoWDehgOww=='}}
'@apm-js-collab/code-transformer@0.8.2' -> {'resolution': {'integrity': 'sha512-YRjJjNq5KFSjDUoqu5pFUWrrsvGOxl6c3bu+uMFc9HNNptZ2rNU/TI2nLw4jnhQNtka972Ee2m3uqbvDQtPeCA=='}}
Interesting! The pnpm-lock.yaml uses the "snapshots"-style format with keys like 7zip-bin@5.2.0 — i.e., the package KEY in the map IS the resolved name@version string. The values don't have a separate name field for these basic entries.
The lockfile is structured differently. Let me re-parse with the right key extraction.
Total keys: 1549 '7zip-bin@5.2.0' '@adobe/css-tools@4.4.4' '@ampproject/remapping@2.3.0' '@antfu/utils@0.7.10' '@apm-js-collab/code-transformer@0.8.2'
So the lockfile v9 uses simple name@version keys. Let me extract the version from the key.
=== MAIN === @astrojs/react: ['5.0.5'] @astrojs/starlight: ['0.39.2'] @astrojs/vercel: ['10.0.7'] @hono/node-server: ['1.19.15', '2.0.10'] @vitejs/plugin-react: ['4.4.1', '5.2.0'] @xmldom/xmldom: ['0.8.13'] app-builder-lib: ['24.13.3', '26.15.7'] astro: ['6.4.8'] body-parser: ['2.2.2'] brace-expansion: ['1.1.16', '2.1.2', '5.0.7'] builder-util-runtime: ['9.2.4', '9.3.1', '9.7.0'] electron-builder: ['26.15.7'] fast-uri: ['3.1.2'] glob: ['10.4.5', '10.5.0', '13.0.6', '7.2.3', '9.3.5'] js-yaml: ['4.2.0', '4.3.0'] minimatch: ['10.2.5', '3.1.5', '5.1.9', '8.0.7', '9.0.9'] plist: ['3.1.0', '3.1.1'] postcss: ['8.5.14'] react-router-dom: ['7.17.0'] sharp: ['0.34.5', '0.35.0'] shell-quote: ['1.8.4'] svgo: ['4.0.1'] tar: ['7.5.16', '7.5.22'] vite: ['6.4.3', '7.3.5'] vite-plugin-svgr: ['3.3.0'] === PR1341 === @astrojs/react: ['5.0.5'] @astrojs/starlight: ['0.39.2'] @astrojs/vercel: ['10.0.7'] @hono/node-server: ['2.0.12'] ...
EXCELLENT! Now I have all the resolution data. Let me analyze carefully:
@xmldom/xmldom: 0.8.13 (PATCHED — within override >=0.8.13 <0.9)brace-expansion: [1.1.16, 2.1.2, 5.0.7] (per-major override was working)fast-uri: 3.1.2@hono/node-server: [1.19.15, 2.0.10] (hono-server is direct in spotlight at ^2.0.10 so 1.19.15 is from elsewhere — likely transitive via MCP. Direct 2.0.10.)react-router-dom: 7.17.0 (vulnerable to #314/#315/#316/#319/#322)vite: [6.4.3, 7.3.5] (the override ceiling works)glob: [13.0.6, 10.4.5, 10.5.0, 7.2.3, 9.3.5] (multiple versions — glob@13.0.6 is used somewhere, likely via @vercel/nft)svgo: 4.0.1 (already 4.x on main — but Dependabot says #305 svgo >=1.0.0 <2.8.3 → 2.8.3; this means main has a 4.0.1 which is OUTSIDE the vulnerable range, so alert #305 is moot. Wait, let me re-check #305)vite-plugin-svgr: 3.3.0@vitejs/plugin-react: [4.4.1, 5.2.0]Now I have resolution data. Let me dig into source code to verify the imports/usage.
packages/website/src/content/docs/docs/contribute/development.mdx:31:### Inspect Sidecar Stream packages/website/src/content/docs/docs/desktop-app/index.mdx:65:- **Traces Tab**: Inspect performance traces and spans packages/website/src/content/docs/docs/mcp/index.mdx:19:- Inspect performance traces and identify bottlenecks
packages/spotlight/src/ui/telemetry/components/events/AICopyButton.tsx:4:import { ReactComponent as CheckIcon } from "@spotlight/ui/assets/check.svg";
packages/spotlight/src/ui/telemetry/components/events/AICopyButton.tsx:5:import { ReactComponent as CopyIcon } from "@spotlight/ui/assets/copy.svg";
packages/spotlight/src/ui/telemetry/components/insights/aiTraces/AITranscription.tsx:1:import { ReactComponent as CrossIcon } from "@spotlight/ui/assets/cross.svg";
packages/spotlight/src/ui/telemetry/components/insights/aiTraces/AITraceList.tsx:1:import { ReactComponent as Sort } from "@spotlight/ui/assets/sort.svg";
packages/spotlight/src/ui/telemetry/components/insights/aiTraces/AITraceList.tsx:2:import { ReactComponent as SortDown } from "@spotlight/ui/assets/sortDown.svg";
packages/spotlight/src/ui/telemetry/components/insights/envelopes/Attachment.test.tsx:7: ReactComponent: () => null,
packages/spotlight/src/ui/telemetry/components/insights/envelopes/Attachment.tsx:2:import { ...
packages/spotlight/src/ui/telemetry/components/events/AICopyButton.tsx:4:import { ReactComponent as CheckIcon } from "@spotlight/ui/assets/check.svg";
packages/spotlight/src/ui/telemetry/components/events/AICopyButton.tsx:5:import { ReactComponent as CopyIcon } from "@spotlight/ui/assets/copy.svg";
packages/spotlight/src/ui/telemetry/components/insights/aiTraces/AITranscription.tsx:1:import { ReactComponent as CrossIcon } from "@spotlight/ui/assets/cross.svg";
packages/spotlight/src/ui/telemetry/components/insights/aiTraces/AITraceList.tsx:1:import { ReactComponent as Sort } from "@spotlight/ui/assets/sort.svg";
packages/spotlight/src/ui/telemetry/components/insights/aiTraces/AITraceList.tsx:2:import { ReactComponent as SortDown } from "@spotlight/ui/assets/sortDown.svg";
packages/spotlight/src/ui/telemetry/components/insights/envelopes/Attachment.tsx:2:import { ReactComponent as Download } from ...
Let me continue searching.
27
packages/spotlight/src/electron/.cursor/rules/electron.mdc:151:Electron uses `HashRouter` instead of `BrowserRouter` because it loads from `file://` protocol:
packages/spotlight/src/electron/.cursor/rules/electron.mdc:156: return <HashRouter>{children}</HashRouter>;
packages/spotlight/src/electron/.cursor/rules/electron.mdc:158:return <BrowserRouter>{children}</BrowserRouter>;
packages/spotlight/src/ui/.cursor/rules/ui.mdc:87:- `BrowserRouter` for standalone web
packages/spotlight/src/ui/.cursor/rules/ui.mdc:88:- `HashRouter` for Electron (file:// protocol)
packages/spotlight/src/ui/.cursor/rules/ui.mdc:93:import { Link, useParams, useSearchParams, useNavigate } from 'react-router-dom';
packages/spotlight/src/ui/.cursor/rules/ui.mdc:100:const navigate = useNavigate();
packages/spotlight/src/ui/lib/Router.tsx:2:import { BrowserRouter, HashRouter } from "react-router-dom";
packages/spotlight/src/ui/lib/Router.tsx:11: * - BrowserRouter for standalone web apps (clean ...
import { resolve } from "node:path";
import tailwindcss from "@tailwindcss/vite";
import react from "@vitejs/plugin-react";
import dts from "vite-plugin-dts";
import svgr from "vite-plugin-svgr";
export const aliases = {
"@spotlight/ui": resolve(__dirname, "src/ui"),
"@spotlight/server": resolve(__dirname, "src/server"),
"@spotlight/shared": resolve(__dirname, "src/shared"),
};
export const defineProduction = {
"process.env.NODE_ENV": '"production"',
"process.env.npm_package_version": JSON.stringify(process.env.npm_package_version),
// Injected version constant for runtime use (especially in fossilized binaries)
__SPOTLIGHT_VERSION__: JSON.stringify(process.env.npm_package_version),
// Set to false for tree-shaking; Electron config overrides to true
__IS_ELECTRON__: false,
};
export const defineDevelopment = {
"process.env.NODE_ENV": '"development"',
"process.env.npm_package_version": JSON.stringify(process.env.npm_package_version),
// Set to false for ...
import { resolve } from "node:path";
import tailwindcss from "@tailwindcss/vite";
import react from "@vitejs/plugin-react";
import dts from "vite-plugin-dts";
import svgr from "vite-plugin-svgr";
export const aliases = {
"@spotlight/ui": resolve(__dirname, "src/ui"),
"@spotlight/server": resolve(__dirname, "src/server"),
"@spotlight/shared": resolve(__dirname, "src/shared"),
};
export const defineProduction = {
"process.env.NODE_ENV": '"production"',
"process.env.npm_package_version": JSON.stringify(process.env.npm_package_version),
// Injected version constant for runtime use (especially in fossilized binaries)
__SPOTLIGHT_VERSION__: JSON.stringify(process.env.npm_package_version),
// Set to false for tree-shaking; Electron config overrides to true
__IS_ELECTRON__: false,
};
export const defineDevelopment = {
"process.env.NODE_ENV": '"development"',
"process.env.npm_package_version": JSON.stringify(process.env.npm_package_version),
// Set to false for ...
Good. Now I have:
exportType: "named", namedExport: "ReactComponent", and include: ["**/*.svg", "**/*.svg?react"]Now let me look at:
import Inspect from "vite-plugin-inspect" in any TS/MJS file. So removal is safe.Wait, the astro.config.mjs originally HAD import Inspect from "vite-plugin-inspect" and used Inspect({ dev: true, build: true }). Removing it means the dev tool just goes away (no /__inspect/ route). That's a feature, not a bug, and it's a dev-only tool.
Let me verify by searching for any usage in source code more comprehensively.
packages/website/.vite-inspect/reports/vite2-prerender/transforms/h6BdYuiBPiSBPq4-gCOuBwWKiY84bjG-4iK-Iygwd_k.json:21: "fileName": "file:///home/byk/Code/getsentry/spotlight/node_modules/.pnpm/vite-plugin-inspect@11.4.1_vite@8.1.5_@types+node@25.5.0_esbuild@0.28.1_jiti@2.7.0_terser@5.43.1_tsx@4.20.3_yaml@2.9.0_/node_modules/vite-plugin-inspect/dist/shared/vite-plugin-inspect.Fv_Ybe1U.mjs", packages/website/.vite-inspect/reports/vite2-prerender/transforms/h6BdYuiBPiSBPq4-gCOuBwWKiY84bjG-4iK-Iygwd_k.json:24: "source": " at InspectContextVite.getEnvContext (file:///home/byk/Code/getsentry/spotlight/node_modules/.pnpm/vite-plugin-inspect@11.4.1_vite@8.1.5_@types+node@25.5.0_esbuild@0.28.1_jiti@2.7.0_terser@5.43.1_tsx@4.20.3_yaml@2.9.0_/node_modules/vite-plugin-inspect/dist/shared/vite-plugin-inspect.Fv_Ybe1U.mjs:195:15)" packages/website/.vite-inspect/reports/vite2-prerender/transforms/h6BdYuiBPiSBPq4-gCOuBwWKiY84bjG-4iK-Iygwd_k.json:27: "fileName": ...
./node_modules/.pnpm/vite-plugin-inspect@0.7.42_rollup@4.60.0_vite@7.3.5_@types+node@25.5.0_jiti@2.4.2_lightningcs_l433k4xk4wdyahy7t4vvqluaae/node_modules/vite-plugin-inspect/package.json:2: "name": "vite-plugin-inspect", ./node_modules/.pnpm/vite-plugin-inspect@0.7.42_rollup@4.60.0_vite@7.3.5_@types+node@25.5.0_jiti@2.4.2_lightningcs_l433k4xk4wdyahy7t4vvqluaae/node_modules/vite-plugin-inspect/package.json:10: "homepage": "https://github.com/antfu/vite-plugin-inspect#readme", ./node_modules/.pnpm/vite-plugin-inspect@0.7.42_rollup@4.60.0_vite@7.3.5_@types+node@25.5.0_jiti@2.4.2_lightningcs_l433k4xk4wdyahy7t4vvqluaae/node_modules/vite-plugin-inspect/package.json:13: "url": "git+https://github.com/antfu/vite-plugin-inspect.git" ./node_modules/.pnpm/vite-plugin-inspect@0.7.42_rollup@4.60.0_vite@7.3.5_@types+node@25.5.0_jiti@2.4.2_lightningcs_l433k4xk4wdyahy7t4vvqluaae/node_modules/vite-plugin-inspect/package.json:16: "url": ...
packages/spotlight/src/ui/vite-env.d.ts:2:/// <reference types="vite-plugin-svgr/client" /> packages/spotlight/vite.config.base.ts:5:import svgr from "vite-plugin-svgr"; packages/spotlight/package.json:133: "vite-plugin-svgr": "^3.3.0",
import starlight from "@astrojs/starlight";
import vercel from "@astrojs/vercel";
import sentry from "@sentry/astro";
import sentryStarlightTheme, {
monochromeCodeTheme,
} from "@sentry/starlight-theme";
import { defineConfig } from "astro/config";
import Inspect from "vite-plugin-inspect";
import tailwindcss from "@tailwindcss/vite";
import react from "@astrojs/react";
// Website entry point: homepage remains custom Astro/Tailwind, while /docs is owned by
// Starlight plus the shared Sentry theme and project-specific docs metadata.
export default defineConfig({
site: "https://spotlightjs.com",
vite: {
plugins: [
Inspect({
dev: true,
build: true,
}),
tailwindcss(),
],
build: {
sourcemap: true,
},
},
devOverlay: true,
integrations: [
sentry({
clientInitPath: "sentry.client.config.mjs",
debug: process.env.NODE_ENV === "development",
sourceMapsUploadOptions: {
project: ...
WAIT! There's a CRITICAL detail I just found. Look at this from the grep output:
packages/spotlight/src/ui/telemetry/components/insights/envelopes/Attachment.test.tsx:7: ReactComponent: () => null,
This is using a Jest-style mock. Let me check this.
Also I see:
./node_modules/.pnpm/vite-plugin-inspect@11.4.1_vite@8.1.5_@types+node@25.5.0_esbuild@0.28.1_jiti@2.7.0_terser@5.43.1_tsx@4.20.3_yaml@2.9.0_/node_modules/vite-plugin-inspect/dist/shared/vite-plugin-inspect.Fv_Ybe1U.mjs
vite-plugin-inspect@11.4.1 (not 12.0.2!) was the version that resolved when used as a transitive dependency of something else. Wait, this is in node_modules. Let me NOT mix this with the .vite-inspect directory in packages/website/. That directory is generated by the plugin and is CHECKED INTO the repo as a build artifact.
But more importantly — vite-plugin-inspect 12.0.2 was published for vite 8, vite-plugin-inspect 11.4.1 was for vite 7-8 transitions, 0.7.42 was original Astro 6 era. ...
import { render, screen } from "@testing-library/react";
import { beforeEach, describe, expect, it, vi } from "vitest";
import Attachment from "./Attachment";
// Mock SVG imports
vi.mock("@spotlight/ui/assets/download.svg", () => ({
ReactComponent: () => null,
}));
// Mock URL.createObjectURL and URL.revokeObjectURL
const mockCreateObjectURL = vi.fn(() => "blob:mock-url");
const mockRevokeObjectURL = vi.fn();
beforeEach(() => {
vi.clearAllMocks();
global.URL.createObjectURL = mockCreateObjectURL;
global.URL.revokeObjectURL = mockRevokeObjectURL;
});
describe("Attachment", () => {
assets favicon.svg index.html reports
# build output dist/ # generated types .astro/ # dependencies node_modules/ # logs npm-debug.log* yarn-debug.log* yarn-error.log* pnpm-debug.log* # environment variables .env .env.production # macOS-specific files .DS_Store --- # Logs logs *.log npm-debug.log* yarn-debug.log* yarn-error.log* pnpm-debug.log* lerna-debug.log* node_modules out dist dist-bin dist-electron node dist-ssr *.local test-results .node-cache # Turbo .turbo # Biome .biome # Editor directories and files .vscode/* !.vscode/extensions.json
OK so:
packages/website/.vite-inspect/ directory exists in the working tree (presumably from a previous run) but isn't .gitignore'd. Not in the PR diff, so it's pre-existing — not part of these PRs. Outside correctness scope.ReactComponent. This is a vitest mock for the named export — exactly matching the new vite-plugin-svgr@5 configuration with namedExport: 'ReactComponent'. So the test is consistent..gitignore doesn't include .vite-inspect/ anywhere. The directory is checked-in dev artifact pollution, not part of this PR.Now let me also verify:
files field change from ["dist"] (single-line array) to multi-line — that's a cosmetic, not correctness. Already filtered.Also check: in PR #1342 the spotlight package version went from 4.11.8 to 4.11.7 (a DOWNGRADE in published version!). ...
50016108 chore(deps): remediate 22 Dependabot alerts via pnpm overrides 041d871e chore(electron): drop redundant notarize afterSign hook (#1336) 43797cca chore(deps): upgrade electron-builder 24 -> 26.15.7 (#1335) d6c318cc release: 4.11.7 fc7a46de release: 4.11.6 30e16099 Fix path stacking in sidebar and detail tabs (React Router v7 splat routes) (#1320) fcbfdadc security(deps): resolve 5 open dependabot alerts (shell-quote, hono) (#1321) 376e51af release: 4.11.5 4597ce36 security(deps): resolve 6 open dependabot alerts (#1316) 2782e3d2 release: 4.11.4 5cc6bbf7 fix(security): resolve dependabot alerts via dep updates and overrides (#1299) 0365d757 chore(deps): bump hono from 4.12.8 to 4.12.14 (#1292) 7a1210e2 chore(deps-dev): bump electron from 35.7.5 to 39.8.5 (#1289) c528fc75 chore(deps-dev): bump happy-dom from 20.8.8 to 20.8.9 (#1287) 020772e1 chore(deps-dev): bump happy-dom from 20.0.2 to 20.8.8 (#1286) b45bc337 chore(deps): bump yaml from 2.8.1 to 2.8.3 (#1283) 781d3115 release: ...
ea3290c9 chore(deps): bump @hono/node-server from 1.19.14 to 2.0.10 (#1338) 3dd00755 chore(deps): bump hono from 4.12.25 to 4.12.27 (#1339) 89131421 release: 4.11.8 041d871e chore(electron): drop redundant notarize afterSign hook (#1336) 43797cca chore(deps): upgrade electron-builder 24 -> 26.15.7 (#1335) d6c318cc release: 4.11.7 fc7a46de release: 4.11.6 30e16099 Fix path stacking in sidebar and detail tabs (React Router v7 splat routes) (#1320) fcbfdadc security(deps): resolve 5 open dependabot alerts (shell-quote, hono) (#1321) 376e51af release: 4.11.5
021ac8ec chore(deps): migrate Astro 6 -> 7 + Vite 8 (closes Dependabot #301 #302) 50016108 chore(deps): remediate 22 Dependabot alerts via pnpm overrides ea3290c9 chore(deps): bump @hono/node-server from 1.19.14 to 2.0.10 (#1338) 3dd00755 chore(deps): bump hono from 4.12.25 to 4.12.27 (#1339) 89131421 release: 4.11.8 041d871e chore(electron): drop redundant notarize afterSign hook (#1336) 826147f1 chore(electron): drop redundant notarize afterSign hook 43797cca chore(deps): upgrade electron-builder 24 -> 26.15.7 (#1335) bcfcf887 chore(deps): upgrade electron-builder 24 -> 26.15.7 d6c318cc release: 4.11.7 fc7a46de release: 4.11.6 30e16099 Fix path stacking in sidebar and detail tabs (React Router v7 splat routes) (#1320) fcbfdadc security(deps): resolve 5 open dependabot alerts (shell-quote, hono) (#1321) 39194389 security(deps): resolve 5 open dependabot alerts (shell-quote, hono) 376e51af release: 4.11.5 4597ce36 security(deps): resolve 6 open dependabot alerts (#1316) 36bdcfd1 ...
Important findings:
4.11.8 (from release commit 89131421)4.11.7 — which is rolling back the version!This is likely a rebase artifact. The branches are based on the 4.11.7 era but the changes were rebased onto main (which has 4.11.8). The version field got reverted to 4.11.7. This is a CORRECTNESS issue because:
Wait but my prior knowledge says these branches are not in main yet. They're staged for merging. ...
...output truncated...
Full output saved to: /home/byk/.local/share/opencode/tool-output/tool_fa8b5d418001clhFXQQLa7B1ux
,className:`stroke-primary-50 cursor-pointer transition-all`,onClick:r})}var ch=({title:e,titleId:t,...n})=>(0,M.jsxs)(`svg`,{xmlns:`http://www.w3.org/2000/svg`,width:`800px`,height:`800px`,viewBox:`0 0 24 24`,fill:`none`,"aria-labelledby":t,...n,children:[e?(0,M.jsx)(`title`,{id:t,children:e}):null,(0,M.jsx)(`path`,{d:`M12 4H6C4.89543 4 4 4.89543 4 6V18C4 19.1046 4.89543 20 6 20H18C19.1046 20 20 19.1046 20 18V12M9 15V12.5L17.75 3.75C18.4404 3.05964 19.5596 3.05964 20.25 3.75V3.75C20.9404 4.44036 20.9404 5.55964 20.25 6.25L15.5 11L11.5 15H9Z`,stroke:`inherit`,strokeWidth:2,strokeLinecap:`round`,strokeLinejoin:`round`})]}),lh=(0,j.createContext)({sidecarUrl:Cc}),uh=({children:e,context:t})=>(0,M.jsx)(lh.Provider,{value:t,children:e}),dh=()=>{let e=(0,j.useContext)(lh),t=(t=``)=>new URL(t,e.sidecarUrl).href;return{...e,getSidecarUrl:t}};function ...
(no output)
#!/usr/bin/env node
require("dotenv").config();
const builder = require("electron-builder");
let mac = {
target: [
{
target: "default",
arch: ["x64", "arm64"],
},
],
icon: "resources/icons/mac/icon.icns",
hardenedRuntime: true,
gatekeeperAssess: false,
entitlements: "build/entitlements.mac.plist",
entitlementsInherit: "build/entitlements.mac.plist",
cscLink: process.env.CSC_LINK,
cscKeyPassword: process.env.CSC_KEY_PASSWORD,
};
if (!process.env.CSC_LINK || !process.env.CSC_KEY_PASSWORD) {
mac = {
...mac,
target: [
{
target: "default",
arch: ["arm64"],
},
],
identity: null,
};
}
builder.build({
publish: "never",
config: {
appId: "io.sentry.spotlight",
productName: "Spotlight",
asarUnpack: ["resources/**"],
npmRebuild: false,
extraMetadata: {
main: "./dist-electron/main/index.js",
},
directories: {
output: "dist-electron",
},
files: [
...
(no output)
The output was huge. Let me proceed with what I've found and search more carefully for svgo in real code.
Important: search showed that svgo is in node_modules (via transitive dep of vite) but NOT in any first-party package.json or source code. So the "svgo": ">=4.0.2" override is acting on vite/build dependency chain only.
For the override to break anything, we'd need a vite sub-dep that uses svgo's 2.x features. Let me see if vite 6/7 uses svgo 2.x specifically. Actually since vite 5, svgo is used internally with v2 API. Let me see.
Hmm actually, the user said to ignore style/cosmetic stuff. Let me focus on correctness.
Let me now check the actual svgo version that vite uses on main:
=== MAIN === svgo: ['4.0.1'] glob: ['10.4.5', '10.5.0', '13.0.6', '7.2.3', '9.3.5'] minimatch: ['10.2.5', '3.1.5', '5.1.9', '8.0.7', '9.0.9'] brace-expansion: ['1.1.16', '2.1.2', '5.0.7'] @xmldom/xmldom: ['0.8.13'] plist: ['3.1.0', '3.1.1'] app-builder-lib: ['24.13.3', '26.15.7'] electron-builder: ['26.15.7'] electron-builder-squirrel-windows: ['24.13.3'] === PR #1341 === svgo: ['4.0.2'] glob: ['10.4.5', '10.5.0', '7.2.3', '9.3.5'] minimatch: ['10.2.5', '3.1.5', '5.1.9', '8.0.7', '9.0.9'] brace-expansion: ['2.1.3'] @xmldom/xmldom: ['0.9.10'] plist: ['3.1.0', '3.1.1'] app-builder-lib: ['26.15.7'] electron-builder: ['26.15.7'] electron-builder-squirrel-windows: ['24.13.3'] === PR #1342 === svgo: ['4.0.2'] glob: ['10.4.5', '10.5.0', '7.2.3', '9.3.5'] minimatch: ['10.2.5', '3.1.5', '5.1.9', '8.0.7', '9.0.9'] brace-expansion: ['2.1.3'] @xmldom/xmldom: ['0.9.10'] plist: ['3.1.0', '3.1.1'] app-builder-lib: ['26.15.7'] electron-builder: ...
Excellent. Now I have very specific data. Let me also look at the glob 13.0.6 situation:
On main: glob 13.0.6 is resolved (transitively, via @vercel/nft probably).
On PR #1341: glob 13.0.6 is GONE. The override "glob@>=13.0.0": "10.4.5" successfully downgraded glob ≥13 to 10.4.5.
But notice: minimatch@10.2.5 is STILL in the lockfile! Where does it come from?
So minimatch@10.2.5 is the version that needs brace-expansion@^5 (NAMED export expand).
In PR #1341, brace-expansion is at 2.1.3 — that means:
require('brace-expansion').expandexpand named — it exports expandTop (default)CONFIRMED: PR #1341 re-introduces the ...
Version: 2.1.3 Main: index.js Exports: null
Version: 5.0.7
Main: ./dist/commonjs/index.js
Exports: {
".": {
"import": {
"types": "./dist/esm/index.d.ts",
"default": "./dist/esm/index.js"
},
"require": {
"types": "./dist/commonjs/index.d.ts",
"default": "./dist/commonjs/index.js"
}
},
"./package.json": "./package.json"
}
Dependencies: {
"brace-expansion": "^5.0.5"
}
Main: ./dist/commonjs/index.js
var balanced = require('balanced-match');
module.exports = expandTop;
var escSlash = '\0SLASH'+Math.random()+'\0';
var escOpen = '\0OPEN'+Math.random()+'\0';
var escClose = '\0CLOSE'+Math.random()+'\0';
var escComma = '\0COMMA'+Math.random()+'\0';
var escPeriod = '\0PERIOD'+Math.random()+'\0';
---
Not found: /brace-expansion@5.0.7/dist/index.js
Confirms brace-expansion 2.1.3 only has the default export (module.exports = expandTop). The CJS file uses require('brace-expansion').expand would fail because 2.x doesn't have that named export.
And minimatch@10.2.5 uses brace-expansion: "^5.0.5" as a peer dep — but pnpm override 2.x would force it down. Then minimatch@10 calls expand() on brace-expansion v2 → TypeError at runtime.
Let me actually verify what minimatch@10 calls (the destructured expand import). Let me check the actual source:
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.unescape = exports.escape = exports.AST = exports.Minimatch = exports.match = exports.makeRe = exports.braceExpand = exports.defaults = exports.filter = exports.GLOBSTAR = exports.sep = exports.minimatch = void 0;
const brace_expansion_1 = require("brace-expansion");
const assert_valid_pattern_js_1 = require("./assert-valid-pattern.js");
const ast_js_1 = require("./ast.js");
const escape_js_1 = require("./escape.js");
const unescape_js_1 = require("./unescape.js");
const minimatch = (p, pattern, options = {}) => {
(0, assert_valid_pattern_js_1.assertValidPattern)(pattern);
// shortcut: comments match nothing.
if (!options.nocomment && pattern.charAt(0) === '#') {
return false;
}
return new Minimatch(pattern, options).match(p);
};
exports.minimatch = minimatch;
// Optimized checking for the most common glob patterns.
const starDotExtRE = /^\*+([^+@!?*[(]*)$/;
const ...
3:exports.unescape = exports.escape = exports.AST = exports.Minimatch = exports.match = exports.makeRe = exports.braceExpand = exports.defaults = exports.filter = exports.GLOBSTAR = exports.sep = exports.minimatch = void 0;
4:const brace_expansion_1 = require("brace-expansion");
131: braceExpand: (pattern, options = {}) => orig.braceExpand(pattern, ext(def, options)),
149:const braceExpand = (pattern, options = {}) => {
153: if (options.nobrace || !/\{(?:(?!\{).)*\}/.test(pattern)) {
Confirmed: const brace_expansion_1 = require("brace-expansion"); then (0, brace_expansion_1.expand)(...) (the (0, x.y)() pattern) will throw at runtime when brace-expansion is v2.x.
Let me verify by looking at line ~149-160 (where brace_expansion_1 is used in the named export way).
//
// Invalid sets are not expanded.
// a{2..}b -> a{2..}b
// a{b}c -> a{b}c
const braceExpand = (pattern, options = {}) => {
(0, assert_valid_pattern_js_1.assertValidPattern)(pattern);
// Thanks to Yeting Li <https://github.com/yetingli> for
// improving this regexp to avoid a ReDOS vulnerability.
if (options.nobrace || !/\{(?:(?!\{).)*\}/.test(pattern)) {
// shortcut. no need to expand.
return [pattern];
}
return (0, brace_expansion_1.expand)(pattern, { max: options.braceExpandMax });
};
exports.braceExpand = braceExpand;
exports.minimatch.braceExpand = exports.braceExpand;
// parse a component of the expanded set.
// At this point, no pattern may contain "/" in it
// so we're going to return a 2d array, where each entry is the full
// pattern, split on '/', and then turned into a regular expression.
// A regexp is made at the end which joins each array with an
// escaped /, and another full one which joins each regexp with |. ...
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.EXPANSION_MAX_LENGTH = exports.EXPANSION_MAX = void 0;
exports.expand = expand;
const balanced_match_1 = require("balanced-match");
const escSlash = '\0SLASH' + Math.random() + '\0';
const escOpen = '\0OPEN' + Math.random() + '\0';
const escClose = '\0CLOSE' + Math.random() + '\0';
const escComma = '\0COMMA' + Math.random() + '\0';
const escPeriod = '\0PERIOD' + Math.random() + '\0';
const escSlashPattern = new RegExp(escSlash, 'g');
const escOpenPattern = new RegExp(escOpen, 'g');
const escClosePattern = new RegExp(escClose, 'g');
const escCommaPattern = new RegExp(escComma, 'g');
const escPeriodPattern = new RegExp(escPeriod, 'g');
const slashPattern = /\\\\/g;
const openPattern = /\\{/g;
const closePattern = /\\}/g;
const commaPattern = /\\,/g;
const periodPattern = /\\\./g;
exports.EXPANSION_MAX = 100_000;
// `EXPANSION_MAX` caps the *number* of expansions, but not their length. ...
CONFIRMED IRREFUTABLY:
minimatch@10.2.5 line 155: return (0, brace_expansion_1.expand)(pattern, ...);
expandbrace-expansion@5.0.8 line 4: exports.expand = expand; — exports expand as named
brace-expansion@2.1.3: module.exports = expandTop; — ONLY default export, NO named expand
So when minimatch@10.2.5 (which IS in PR #1341's lockfile) is required by app-builder-lib@26.15.7 → electron-builder → DMG/zip building, it'll do (0, brace_expansion_1.expand)(...) which throws TypeError: (0, brace_expansion_1.expand) is not a function.
This BREAKS the macOS build.
PR #1341 re-introduces the EXACT bug that PR #1337 fixed.
Let me also verify the @xmldom/xmldom 0.9.10 issue.
Version: 0.9.10 Main: lib/index.js Files: None
'use strict';
var conventions = require('./conventions');
var dom = require('./dom');
var errors = require('./errors');
var entities = require('./entities');
var sax = require('./sax');
var DOMImplementation = dom.DOMImplementation;
var hasDefaultHTMLNamespace = conventions.hasDefaultHTMLNamespace;
var isHTMLMimeType = conventions.isHTMLMimeType;
var isValidMimeType = conventions.isValidMimeType;
var MIME_TYPE = conventions.MIME_TYPE;
var NAMESPACE = conventions.NAMESPACE;
var ParseError = errors.ParseError;
var XMLReader = sax.XMLReader;
/**
* Normalizes line ending according to <https://www.w3.org/TR/xml11/#sec-line-ends>,
* including some Unicode "newline" characters:
*
* > XML parsed entities are often stored in computer files which,
* > for editing convenience, are organized into lines.
* > These lines are typically separated by some combination
* > of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA). ...
89: * When the `mimeType` for HTML, XHTML or SVG are passed to `parseFromString`,
181: * When the `mimeType` for HTML, XHTML or SVG are passed to `parseFromString`,
193: * `DOMParser`. If `mimeType` is `text/html` an HTML `Document` is created,
208: * @param {string} [mimeType='application/xml']
209: * the mimeType or contentType of the document to be created determines the `type` of document
216: * for any invalid `mimeType`
217: * @see https://developer.mozilla.org/en-US/docs/Web/API/DOMParser/parseFromString
220:DOMParser.prototype.parseFromString = function (source, mimeType) {
221: if (!isValidMimeType(mimeType)) {
222: throw new TypeError('DOMParser.parseFromString: the provided mimeType "' + mimeType + '" is not valid.');
227: if (hasDefaultHTMLNamespace(mimeType)) {
230: } else if (mimeType === MIME_TYPE.XML_SVG_IMAGE) {
237: mimeType: mimeType,
249: var isXml = !conventions.isHTMLMimeType(mimeType);
262: * @property {string} ...
CONFIRMED: @xmldom/xmldom@0.9.10 line 220-222:
DOMParser.prototype.parseFromString = function (source, mimeType) {
if (!isValidMimeType(mimeType)) {
throw new TypeError('DOMParser.parseFromString: the provided mimeType "' + mimeType + '" is not valid.');
The mimeType argument is REQUIRED. The 0.8.x version defaulted to undefined (with fallback). In 0.9.x it strictly validates.
Now what does plist@3.1.0 (which is in the lockfile) call?
Let me check.
(function(f){if(typeof exports==="object"&&typeof module!=="undefined"){module.exports=f()}else if(typeof define==="function"&&define.amd){define([],f)}else{var g;if(typeof window!=="undefined"){g=window}else if(typeof global!=="undefined"){g=global}else if(typeof self!=="undefined"){g=self}else{g=this}g.plist = f()}})(function(){var define,module,exports;return (function(){function r(e,n,t){function o(i,f){if(!n[i]){if(!e[i]){var c="function"==typeof require&&require;if(!f&&c)return c(i,!0);if(u)return u(i,!0);var a=new Error("Cannot find module '"+i+"'");throw a.code="MODULE_NOT_FOUND",a}var p=n[i]={exports:{}};e[i][0].call(p.exports,function(r){var n=e[i][1][r];return o(n||r)},p,p.exports,r,e,n,t)}return n[i].exports}for(var u="function"==typeof require&&require,i=0;i<t.length;i++)o(t[i]);return o}return r})()({1:[function(require,module,exports){
(function (Buffer){(function (){
/**
* Module dependencies. ...
/**
* Module dependencies.
*/
const { DOMParser } = require('@xmldom/xmldom');
/**
* Module exports.
*/
exports.parse = parse;
var TEXT_NODE = 3;
var CDATA_NODE = 4;
var COMMENT_NODE = 8;
/**
* We ignore raw text (usually whitespace), <!-- xml comments -->,
* and raw CDATA nodes.
*
* @param {Element} node
* @returns {Boolean}
* @api private
*/
function shouldIgnoreNode (node) {
return node.nodeType === TEXT_NODE
|| node.nodeType === COMMENT_NODE
|| node.nodeType === CDATA_NODE;
}
/**
* Check if the node is empty. Some plist file has such node:
* <key />
* this node shoud be ignored.
*
* @see https://github.com/TooTallNate/plist.js/issues/66
* @param {Element} node
* @returns {Boolean}
* @api private
*/
function isEmptyNode(node){
if(!node.childNodes || node.childNodes.length === 0) {
return true;
} else {
return false;
}
}
latest: 5.0.0
plist@3.1.0 calls DOMParser.parseFromString but let me find the actual call site.
5:const { DOMParser } = require('@xmldom/xmldom');
66: var doc = new DOMParser().parseFromString(xml);
CATASTROPHIC CONFIRMATION: plist@3.1.0 line 66: var doc = new DOMParser().parseFromString(xml);
It calls parseFromString(xml) with NO mimeType argument. Combined with @xmldom/xmldom@0.9.10 line 220-222:
DOMParser.prototype.parseFromString = function (source, mimeType) {
if (!isValidMimeType(mimeType)) {
throw new TypeError('DOMParser.parseFromString: the provided mimeType "' + mimeType + '" is not valid.');
So in plist@3.1.0 → @xmldom/xmldom@0.9.10, calling parseFromString(xml) will throw TypeError: DOMParser.parseFromString: the provided mimeType "undefined" is not valid. — exactly the bug PR #1337 fixed.
PR #1341 re-introduces the EXACT bug that PR #1337 fixed.
This is in app-builder-lib@26.15.7 → plist@3.1.0 (also in @electron/osx-sign's chain via osx-sign's signing behavior for entitlements .plist). This will break build:mac.
Now let me look at the website build implications for PR #1342:
Version: 5.2.0
Dependencies: {
"@rollup/pluginutils": "^5.3.0",
"@svgr/core": "^8.1.0",
"@svgr/plugin-jsx": "^8.1.0"
}
peerDependencies: {
"vite": ">=3.0.0"
}
import { createFilter } from "@rollup/pluginutils";
import fs from "node:fs";
//#region src/index.ts
function vitePluginSvgr({ svgrOptions, esbuildOptions, oxcOptions, include = "**/*.svg?react", exclude } = {}) {
const filter = createFilter(include, exclude);
const postfixRE = /[?#].*$/s;
return {
name: "vite-plugin-svgr",
enforce: "pre",
async load(id) {
if (!filter(id)) return;
const filePath = id.replace(postfixRE, "");
const svgCode = await fs.promises.readFile(filePath, "utf8");
const { transform: svgrTransform } = await import("@svgr/core");
const { default: jsx } = await import("@svgr/plugin-jsx");
const componentCode = await svgrTransform(svgCode, svgrOptions, {
filePath,
caller: { defaultPlugins: [jsx] }
});
if ((this?.meta)?.rolldownVersion != null) {
/* c8 ignore next */
const { transformWithOxc } = await import("vite");
return {
code: (await transformWithOxc(componentCode, id, {
lang: ...
Now I see the vite-plugin-svgr@5 code:
function vitePluginSvgr({ svgrOptions, esbuildOptions, oxcOptions, include = "**/*.svg?react", exclude } = {}) {
const filter = createFilter(include, exclude);
The DEFAULT include is **/*.svg?react — meaning *.svg (no ?react suffix) is NOT included by default. The PR adds include: ["**/*.svg", "**/*.svg?react"] to cover both. Good.
Now let me check exportType: "named" and namedExport: "ReactComponent" — these are svgrOptions passed to @svgr/core. Let me verify they actually work as advertised:
Version: 8.1.0
88: namedExport: "ReactComponent", 89: exportType: "default"
72: exportType: config.exportType, 73: namedExport: config.namedExport
@vitejs/plugin-jsx takes exportType and namedExport from config. So when svgrOptions.exportType: "named" and namedExport: "ReactComponent" are passed, the JSX plugin generates React component exports correctly.
But there's a subtle issue: the @svgr/plugin-jsx DEFAULT is namedExport: "ReactComponent" / exportType: "default" (line 88-89 above shows defaults). Let me look more carefully...
Actually re-checking: line 88-89 says:
namedExport: "ReactComponent",
exportType: "default"
These look like the DEFAULTS of plugin-jsx. But wait, "named" export type with "default" is contradictory. Let me read the surrounding code.
ref: config.ref,
titleProp: config.titleProp,
descProp: config.descProp,
expandProps: config.expandProps,
dimensions: config.dimensions,
icon: config.icon,
native: config.native,
svgProps: config.svgProps,
replaceAttrValues: config.replaceAttrValues,
typescript: config.typescript,
template: config.template,
memo: config.memo,
exportType: config.exportType,
namedExport: config.namedExport
}, getJsxRuntimeOptions(config)), {
state
});
const result = core.transformFromAstSync(babelTree, code, __spreadValues({
caller: {
name: "svgr"
},
presets: [
core.createConfigItem([svgrBabelPreset, svgPresetOptions], {
type: "preset"
})
],
filename: filePath,
babelrc: false,
configFile: false,
code: true,
ast: false,
OK so the code passes exportType: config.exportType, namedExport: config.namedExport correctly from the options forwarded.
Looking at the @svgr/plugin-jsx defaults — let me look at where line 88-89 are.
],
filename: filePath,
babelrc: false,
configFile: false,
code: true,
ast: false,
// @ts-ignore
inputSourceMap: false
}, config.jsx && config.jsx.babelConfig));
if (!(result == null ? void 0 : result.code)) {
throw new Error(`Unable to generate SVG file`);
}
return result.code;
};
module.exports = jsxPlugin;
'use strict';
var svgParser = require('svg-parser');
var hastToBabelAst = require('@svgr/hast-util-to-babel-ast');
var core = require('@babel/core');
var svgrBabelPreset = require('@svgr/babel-preset');
var __defProp = Object.defineProperty;
var __defProps = Object.defineProperties;
var __getOwnPropDescs = Object.getOwnPropertyDescriptors;
var __getOwnPropSymbols = Object.getOwnPropertySymbols;
var __hasOwnProp = Object.prototype.hasOwnProperty;
var __propIsEnum = Object.prototype.propertyIsEnumerable;
var __defNormalProp = (obj, key, value) => key in obj ? __defProp(obj, key, { enumerable: true, configurable: true, writable: true, value }) : obj[key] = value;
var __spreadValues = (a, b) => {
for (var prop in b || (b = {}))
if (__hasOwnProp.call(b, prop))
__defNormalProp(a, prop, b[prop]);
if (__getOwnPropSymbols)
for (var prop of __getOwnPropSymbols(b)) {
if (__propIsEnum.call(b, prop))
__defNormalProp(a, prop, b[prop]);
}
return a;
};
var ...
OK so the @svgr/plugin-jsx passes exportType: config.exportType, namedExport: config.namedExport to the babel-preset options. These get exposed to the babel preset's SVG template. So if vite.config.base.ts passes svgrOptions: { exportType: "named", namedExport: "ReactComponent" }, the .svg transform produces:
export const ReactComponent = (props) => ...
That matches the imports in all 27 .tsx files.
Wait, what about jsxRuntime: "automatic" vs "classic"? The config doesn't set jsxRuntime, so it defaults to "classic" with import React from 'react'. That means in classic mode:
import React from "react")React.createElement(...)Actually wait, with jsxRuntime: "classic", the compiled output is:
import React from 'react';
const ReactComponent = (props) => React.createElement('svg', { ... }, ...);
The existing .tsx files have import { ReactComponent as X } from "./foo.svg". ...
(no output)
No @xmldom/xmldom in the alert history at all. So the @xmldom/xmldom 0.9.10 doesn't directly have an open alert, BUT it breaks plist@3.1.0 → app-builder-lib@26 → build:mac. This is the lored gotcha that PR #1337 fixed.
Now let me count what alerts the PR is actually closing. Look at resolved versions vs each alert:
| Alert | Range | Patched | Resolved PR #1341 | Closed? | |-------|-------|---------|-------------------|---------| | #323 brace-expansion | ≤5.0.7 | 5.0.8 | 2.1.3 | ✓ (forced away from 5.x) | | #322 react-router | ≥7.12.0 <8.3.0 | 8.3.0 | 7.18.1 (react-router-dom) | ✗ NO (no 8.x exists; see lore note) | | #321 tar | ≤7.5.20 | 7.5.21 | 7.5.22 | ✓ | | #320 postcss | ≤8.5.17 | 8.5.18 | 8.5.24 | ✓ | | #319 react-router | ≥7.0.0 <7.18.0 | 7.18.0 | 7.18.1 (react-router-dom) | ✓ | | #318 builder-util-runtime | <9.7.0 | 9.7.0 | 9.7.0 | ✓ | | #317 app-builder-lib | <26.15.0 | 26.15.0 | 26.15.7 | ✓ | | #316 react-router | ≥6.0.0 <7.18.0 | 7.18.0 | 7.18.1 | ✓ | | #315 react-router ...
glob key: glob@10.4.5 deps: [] peer: None peerDeps: None glob key: glob@10.5.0 deps: [] peer: None peerDeps: None glob key: glob@7.2.3 deps: [] peer: None peerDeps: None glob key: glob@9.3.5 deps: [] peer: None peerDeps: None
Hmm — glob entries don't have inline dependencies in pnpm-lock v9 format. The dependencies are flattened to dedicated package entries. Let me see if glob entries have a dependencies block that lists "minimatch" as a string (which is what pnpm does):
=== entries with glob path ===
glob@10.4.5:
resolution: {integrity: sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==}
deprecated: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
hasBin: true
glob@10.5.0:
--
glob@10.4.5:
dependencies:
foreground-child: 3.3.0
jackspeak: 3.4.3
minimatch: 9.0.9
minipass: 7.1.3
---
glob@10.5.0:
resolution: {integrity: sha512-DfXN8DfhJ7NH3Oe7cFmu3NCu1wKbkReJ8TorzSAFbSKrlNaQSKfIzqYqVY8zlbs2NLBbWpRiU52GX2PbaBVNkg==}
deprecated: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
hasBin: true
...
Now I see the structure better — pnpm-lock v9 uses YAML document structure where glob@10.4.5 appears multiple times (once with metadata, once with dependencies). Let me find the nested structure.
Wait, the entries appear duplicated. Let me look at the full structure of the lockfile.
lockfileVersion: '9.0'
settings:
autoInstallPeers: true
excludeLinksFromLockfile: false
catalogs:
default:
'@fontsource/raleway':
specifier: ^5.1.0
version: 5.2.5
'@sentry/astro':
specifier: ^10.31.0
version: 10.32.1
'@sentry/core':
specifier: ^10.31.0
version: 10.32.1
'@sentry/node':
specifier: ^10.31.0
version: 10.32.1
'@tailwindcss/vite':
specifier: ^4.1.11
version: 4.1.11
'@types/node':
specifier: ^22.15.21
version: 22.15.28
'@types/react':
specifier: ^18.3.11
version: 18.3.20
'@types/react-dom':
specifier: ^18.3.0
version: 18.3.7
react:
specifier: ^18.3.1
version: 18.3.1
react-dom:
specifier: ^18.3.1
version: 18.3.1
tailwindcss:
specifier: ^4.1.10
4181: glob@10.4.5: 11553: glob@10.4.5: --- 5216: minimatch@10.2.5: 12935: minimatch@10.2.5:
The lockfile YAML has multiple documents (separated by ---). The pnpm-lock.yaml uses YAML multi-document format. Let me look at the structure.
engines: {node: '>= 6'}
glob-parent@6.0.2:
resolution: {integrity: sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==}
engines: {node: '>=10.13.0'}
glob@10.4.5:
resolution: {integrity: sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==}
deprecated: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
hasBin: true
glob@10.5.0:
resolution: {integrity: sha512-DfXN8DfhJ7NH3Oe7cFmu3NCu1wKbkReJ8TorzSAFbSKrlNaQSKfIzqYqVY8zlbs2NLBbWpRiU52GX2PbaBVNkg==}
deprecated: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. ...
glob-parent@5.1.2:
dependencies:
is-glob: 4.0.3
glob-parent@6.0.2:
dependencies:
is-glob: 4.0.3
glob@10.4.5:
dependencies:
foreground-child: 3.3.0
jackspeak: 3.4.3
minimatch: 9.0.9
minipass: 7.1.3
package-json-from-dist: 1.0.1
path-scurry: 1.11.1
glob@10.5.0:
dependencies:
foreground-child: 3.3.0
jackspeak: 3.4.3
minimatch: 9.0.9
minipass: 7.1.3
package-json-from-dist: 1.0.1
path-scurry: 1.11.1
glob@7.2.3:
dependencies:
fs.realpath: 1.0.0
inflight: 1.0.6
inherits: 2.0.4
minimatch: 3.1.5
once: 1.4.0
path-is-absolute: 1.0.1
glob@9.3.5:
dependencies:
fs.realpath: 1.0.0
minimatch: 8.0.7
minipass: 4.2.8
path-scurry: 1.11.1
global-agent@3.0.0:
dependencies:
boolean: 3.2.0
es6-error: 4.1.1
matcher: 3.0.0
roarr: 2.15.4
semver: 7.7.4
serialize-error: 7.0.1
optional: ...
Now I can see clearly:
glob@10.4.5 uses minimatch: 9.0.9 — NOT 10.x.
glob@10.5.0 uses minimatch: 9.0.9 — also 9.x.
glob@7.2.3 uses minimatch: 3.1.5 — 3.x.
So all glob versions in lockfile pull minimatch@9.0.9 or older. None pull minimatch@10. So where does minimatch@10.2.5 come from?
Let me search.
minimatch@10.2.5:
resolution: {integrity: sha512-MULkVLfKGYDFYejP07QOurDLLQpcjk7Fw+7jXS2R2czRQzR56yHRveU5NDJEOviH+hETZKSkIk5c+T23GjFUMg==}
engines: {node: 18 || 20 || >=22}
minimatch@3.1.5:
resolution: {integrity: sha512-VgjWUsnnT6n+NUk6eZq77zeFdpW2LWDzP6zFGrCbHXiYNul5Dzqk2HHQ5uFH2DNW5Xbp8+jVzaeNt94ssEEl4w==}
minimatch@5.1.9:
resolution: {integrity: sha512-7o1wEA2RyMP7Iu7GNba9vc0RWWGACJOCZBJX2GJWip0ikV+wcOsgVuY9uE8CPiyQhkGFSlhuSkZPavN7u1c2Fw==}
engines: {node: '>=10'}
minimatch@8.0.7:
resolution: {integrity: sha512-V+1uQNdzybxa14e/p00HZnQNNcTjnRJjDxg2V8wtkjFctq4M7hXFws4oekyTP0Jebeq7QYtpFyOeBAjc88zvYg==}
engines: {node: '>=16 || 14 >=14.17'}
minimatch@9.0.9:
--
minimatch@10.2.5:
dependencies:
brace-expansion: 2.1.3
minimatch@3.1.5:
dependencies:
brace-expansion: 2.1.3
minimatch@5.1.9:
dependencies:
brace-expansion: 2.1.3
5216: minimatch@10.2.5: 5231: minimatch@9.0.9: 12935: minimatch@10.2.5: 12951: minimatch@9.0.9:
Interesting! At line 12935:
minimatch@10.2.5:
dependencies:
brace-expansion: 2.1.3
So pnpm IS forcing minimatch@10.2.5's brace-expansion dep to 2.1.3 (via the override). Pnpm recorded this as the chosen resolution. But at RUNTIME, minimatch@10.2.5's actual require code does brace_expansion_1.expand which is NOT a function in 2.1.3.
Wait, let me re-look at minimatch@10.2.5 source. Maybe its expand is actually NOT used at runtime in the typical paths.
Let me grep minimatch's brace_expansion_1.expand usage.
4:const brace_expansion_1 = require("brace-expansion");
157: return (0, brace_expansion_1.expand)(pattern, { max: options.braceExpandMax });
minimatch@10 has exactly ONE call to brace_expansion_1.expand, at line 157. It's the braceExpand function — called when user invokes minimatch.braceExpand(pattern) or includes braces {a,b} in their pattern.
Now in app-builder-lib@26.15.7's chain, IS braceExpand actually invoked? Let me see.
Version: 26.15.7
Dependencies: {
"ajv": "^8.18.0",
"ejs": "^3.1.8",
"tar": "^7.5.7",
"jiti": "^2.4.2",
"debug": "^4.3.4",
"json5": "^2.2.3",
"pkijs": "^3.4.0",
"plist": "3.1.0",
"which": "^5.0.0",
"asn1js": "^3.0.10",
"dotenv": "^16.4.5",
"semver": "~7.7.3",
"ci-info": "4.3.1",
"js-yaml": "^4.1.0",
"resedit": "^1.7.0",
"fs-extra": "^10.1.0",
"lazy-val": "^1.0.5",
"unzipper": "^0.12.3",
"minimatch": "^10.2.5",
"temp-file": "^3.4.0",
"builder-util": "26.15.3",
"isbinaryfile": "^5.0.0",
"@electron/get": "^3.0.0",
"@noble/hashes": "^2.2.0",
"dotenv-expand": "^11.0.6",
"@electron/asar": "3.4.1",
"@electron/fuses": "^1.8.0",
"@types/fs-extra": "9.0.13",
"async-exit-hook": "^2.0.1",
"hosted-git-info": "^4.1.0",
"proper-lockfile": "^4.1.2",
"tiny-async-pool": "1.3.0",
"electron-publish": "26.15.3",
"@electron/rebuild": "^4.0.4",
"@electron/notarize": "2.5.0",
"@electron/osx-sign": "1.3.3",
"chromium-pickle-js": ...
latest: 2.6.0
latest: 5.2.0
latest: 1.0.11
app-builder-lib@26.15.7 directly depends on minimatch: "^10.2.5". This is the chain where minimatch@10 calls brace_expansion_1.expand. If app-builder-lib actually invokes braceExpand, we get the TypeError.
Let me search for usages:
(no output)
(no output)
(no output)
Let me find app-builder-lib source files online to confirm minimatch.braceExpand usage:
Not found: /app-builder-lib@26.15.7/out/util/appFileMatcher.js
(no output)
Let me look at the actual paths in the package:
Main: out/index.js Files: None
(no output)
/home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/helpers/dynamic-import.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/helpers/remote-rebuild.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/asar/asar.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/asar/asarFileChecker.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/asar/asarUtil.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/asar/integrity.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/asar/unpackDetector.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/codeSign/codesign.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/codeSign/macCodeSign.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/codeSign/signManager.js
Found app-builder-lib@26.8.1 (close to 26.15.7). Let me check fileMatcher.
/home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/config/config.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/config/load.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/AppFileWalker.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/NodeModuleCopyHelper.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/appBuilder.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/appFileCopier.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/asyncEventEmitter.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/bundledTool.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/cacheManager.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/filter.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/flags.js /home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/hash.js /home/byk/.bun/install/cache/app-buil...
appInfo.d.ts appInfo.js appInfo.js.map asar binDownload.d.ts binDownload.js binDownload.js.map codeSign configuration.d.ts configuration.js configuration.js.map core.d.ts core.js core.js.map electron errorMessages.d.ts errorMessages.js errorMessages.js.map fileMatcher.d.ts fileMatcher.js fileMatcher.js.map fileTransformer.d.ts fileTransformer.js fileTransformer.js.map forge-maker.d.ts forge-maker.js forge-maker.js.map Framework.d.ts Framework.js Framework.js.map frameworks index.d.ts index.js index.js.map linuxPackager.d.ts linuxPackager.js linuxPackager.js.map macPackager.d.ts macPackager.js macPackager.js.map node-module-collector options packagerApi.d.ts packagerApi.js packagerApi.js.map packager.d.ts packager.js packager.js.map platformPackager.d.ts platformPackager.js platformPackager.js.map presets ProtonFramework.d.ts ProtonFramework.js ProtonFramework.js.map publish targets toolsets util version.d.ts version.js version.js.map vm wine.d.ts wine.js wine.js.map winPackager.d.ts wi...
Let me grep for braceExpand or minimatch in the actual app-builder-lib source:
/home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/filter.js:50: return minimatchAll(relative, patterns, stat) && (excludePatterns == null || stat.isDirectory() || !minimatchAll(relative, excludePatterns, stat));
/home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/filter.js:53:// https://github.com/joshwnj/minimatch-all/blob/master/index.js
/home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/filter.js:54:function minimatchAll(path, patterns, stat) {
/home/byk/.bun/install/cache/app-builder-lib@26.8.1@@@1/out/util/filter.js.map:1:{"version":3,"file":"filter.js","sourceRoot":"","sources":["../../src/util/filter.ts"],"names":[],"mappings":";;AAKA,4BAaC;AAoBD,oCAmBC;AAvDD,6BAA4B;AAE5B,gBAAgB;AAChB,SAAgB,QAAQ,CAAC,OAAkB;IACzC,MAAM,GAAG,GAAG,OAAO,CAAC,GAAG,CAAA;IACvB,IAAI,GAAG,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QACnB,OAAO,IAAI,CAAA;IACb,CAAC;IAED,KAAK,MAAM,CAAC,IAAI,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC;QACvB,IAAI,OAAO,CAAC,KAAK,QAAQ,EAAE,CAAC;YAC1B,OAAO,IAA...
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.hasMagic = hasMagic;
exports.createFilter = createFilter;
const path = require("path");
/** @internal */
function hasMagic(pattern) {
const set = pattern.set;
if (set.length > 1) {
return true;
}
for (const i of set[0]) {
if (typeof i !== "string") {
return true;
}
}
return false;
}
// sometimes, destination may not contain path separator in the end (path to folder), but the src does. So let's ensure paths have path separators in the end
function ensureEndSlash(s) {
return s.length === 0 || s.endsWith(path.sep) ? s : s + path.sep;
}
function getRelativePath(file, srcWithEndSlash, stat) {
let relative = stat.moduleFullFilePath || file.substring(srcWithEndSlash.length);
if (path.sep === "\\") {
if (relative.startsWith("\\")) {
// windows problem: double backslash, the above substring call removes root path with a ...
So app-builder-lib@26 imports minimatch via new minimatch_1.Minimatch(relativeFrom, minimatchOptions). The Minimatch constructor is the typical path-matching class. This doesn't directly call braceExpand.
But Minimatch internally does brace expansion during matching. When you construct new Minimatch("foo/{a,b}") and call .match(), the brace expansion happens via braceExpand. Let me trace:
3:exports.unescape = exports.escape = exports.AST = exports.Minimatch = exports.match = exports.makeRe = exports.braceExpand = exports.defaults = exports.filter = exports.GLOBSTAR = exports.sep = exports.minimatch = void 0;
131: braceExpand: (pattern, options = {}) => orig.braceExpand(pattern, ext(def, options)),
149:const braceExpand = (pattern, options = {}) => {
159:exports.braceExpand = braceExpand;
160:exports.minimatch.braceExpand = exports.braceExpand;
268: this.globSet = [...new Set(this.braceExpand())];
897: braceExpand() {
898: return (0, exports.braceExpand)(this.pattern, this.options);
Found it! minimatch@10 line 268: this.globSet = [...new Set(this.braceExpand())];
This is in the Minimatch constructor! So every new Minimatch(pattern) will call this.braceExpand() → (0, exports.braceExpand)(this.pattern, ...) → (0, brace_expansion_1.expand)(...) which throws if brace-expansion is v2.
So: every Minimatch construction in app-builder-lib (fileMatcher.js line 69: new Minimatch(relativeFrom)) will crash at macOS package sign / file matching step if brace-expansion is forced to 2.x.
This is DEFINITIVELY the same bug PR #1337 fixed. PR #1341 re-introduces it.
But wait — earlier PR #1335 added per-major ranges that allowed brace-expansion@^5 to satisfy minimatch@10's needs. Let me trace:
Earlier PR (#1337 style):
"brace-expansion@<2.0.0": ">=1.1.12 <2",
"brace-expansion@>=2.0.0 <3.0.0": ">=2.1.2 <3",
"brace-expansion@>=3.0.0 <4.0.0": ">=3.0.1 <4",
"brace-expansion@>=4.0.0": ">=4.0.1",
With these per-major rules, brace-expansion@>=4.0.0 ...
(no output)
...output truncated...
Full output saved to: /home/byk/.local/share/opencode/tool-output/tool_fa8bb020d001ieilmPYYccQvMR
packages/spotlight/src/ui/telemetry/components/insights/envelopes/CodeViewer.tsx:1:import { transformerNotationHighlight } from "@shikijs/transformers";
packages/spotlight/src/ui/telemetry/components/insights/envelopes/CodeViewer.tsx:3:import { SHIKI_DEFAULT_THEME } from "@spotlight/ui/shiki-constants";
packages/spotlight/src/ui/telemetry/components/insights/envelopes/CodeViewer.tsx:1:import { transformerNotationHighlight } from "@shikijs/transformers";
packages/spotlight/src/ui/telemetry/components/insights/envelopes/CodeViewer.tsx:3:import { SHIKI_DEFAULT_THEME } from "@spotlight/ui/shiki-constants";
packages/spotlight/src/ui/telemetry/components/insights/envelopes/CodeViewer.tsx:4:import { bundledLanguages } from "shiki/bundle-web.mjs";
packages/spotlight/src/ui/ShikiProvider.tsx:2:import { type Highlighter, bundledLanguages, createHighlighter } from "shiki/bundle-web.mjs";
packages/spotlight/src/ui/sentinel-theme.ts:1:import type { ThemeRegistration } from "shiki";
Wait — shiki IS actively used in the spotlight package via:
import { bundledLanguages, createHighlighter } from "shiki/bundle-web.mjs"import type { ThemeRegistration } from "shiki"And the spotlight package.json has "shiki": "^3.13.0" in devDependencies.
So shiki is NOT vestigial in spotlight. The .lore.md note about "shiki ^3.13.0 in website is vestigial" was specifically about the WEBSITE package, not spotlight. Let me re-check: is shiki 3 used in packages/website?
(no output)
30: "shiki": "^3.13.0",
Yes, packages/website/package.json has "shiki": "^3.13.0" (devDep) but no src import. The .lore.md note is correct: "shiki ^3.13.0 in website is vestigial (no imports)".
This means packages/website's shiki@3.13.0 IS dead code in the website. But the package.json still has it. Per lore, "astro 7 transitively pulls shiki@^4.0.2" so the website's shiki is unused.
OK — that's a residual cleanup but not correctness.
Now let me also check the rest of the package.json diffs more carefully. Looking at the PR diff for #1342 (combining all relevant ones):
PR #1342 deltas from #1341:
Looking again at #1341:
"vite@>=6.0.0 <6.4.2": "~6.4.2", // kept from main
But the vite@>=7.0.0 <7.3.5: ">=7.3.5 <8" override from main is REMOVED in PR #1341 — yes confirmed. So vite 7.4+ and 8.x have no floor in PR #1341. Current resolution stays at 7.3.5 because ...
vite@8.1.5:
resolution: {integrity: sha512-7ULLwsCdYx/nRyrpiEwvqb5TFHrMVZyBt+rg/OAXT7rgj/z+DtTDyKFeLAdDkubDVDKD8jOsndmy7m55XcfUsw==}
engines: {node: ^20.19.0 || >=22.12.0}
hasBin: true
peerDependencies:
'@types/node': ^20.19.0 || >=22.12.0
'@vitejs/devtools': ^0.3.0
esbuild: '>=0.28.1'
jiti: '>=1.21.0'
less: ^4.0.0
sass: ^1.70.0
207: version: 4.3.3(vite@8.1.5(@types/node@22.15.28)(esbuild@0.28.1)(jiti@2.7.0)(terser@5.43.1)(tsx@4.20.3)(yaml@2.8.3)) 240: version: 6.0.4(vite@8.1.5(@types/node@22.15.28)(esbuild@0.28.1)(jiti@2.7.0)(terser@5.43.1)(tsx@4.20.3)(yaml@2.8.3)) 348: version: 4.5.4(@types/node@22.15.28)(rollup@4.60.0)(typescript@5.9.2)(vite@8.1.5(@types/node@22.15.28)(esbuild@0.28.1)(jiti@2.7.0)(terser@5.43.1)(tsx@4.20.3)(yaml@2.8.3)) 354: version: 5.2.0(rollup@4.60.0)(typescript@5.9.2)(vite@8.1.5(@types/node@22.15.28)(esbuild@0.28.1)(jiti@2.7.0)(terser@5.43.1)(tsx@4.20.3)(yaml@2.8.3)) 357: version: 4.1.8(@opentelemetry/api@1.9.0)(@types/node@22.15.28)(@vitest/coverage-v8@4.1.8)(happy-dom@20.8.9)(vite@8.1.5(@types/node@22.15.28)(esbuild@0.28.1)(jiti@2.7.0)(terser@5.43.1)(tsx@4.20.3)(yaml@2.8.3)) 387: version: 4.3.3(vite@8.1.5(@types/node@25.5.0)(esbuild@0.28.1)(jiti@2.7.0)(terser@5.43.1)(tsx@4.20.3)(yaml@2.9.0)) 2974: '@vitejs/plugin-react@5.2.0': 2980: ...
(no output)
Found @vitejs/plugin-react@5.2.0(vite@8.1.5(...)) — so vite 8.1.5 has @vitejs/plugin-react@5.2.0 as a peer or transitive. Let me check what's at line 7271.
Hmm, line 7271 just shows the deps of something pulling in @vitejs/plugin-react@5.2.0. Let me look further:
'@astrojs/mdx@7.0.4(@astrojs/markdown-satteri@0.3.4)(astro@7.1.4(@astrojs/markdown-remark@7.2.1)(@emnapi/core@1.11.1)(@emnapi/runtime@1.11.1)(@types/node@25.5.0)(@vercel/functions@3.5.1)(jiti@2.7.0)(rollup@4.60.0)(terser@5.43.1)(tsx@4.20.3)(yaml@2.9.0))':
dependencies:
'@astrojs/internal-helpers': 0.10.1
'@astrojs/markdown-remark': 7.2.1
'@mdx-js/mdx': 3.1.1
acorn: 8.16.0
astro: 7.1.4(@astrojs/markdown-remark@7.2.1)(@emnapi/core@1.11.1)(@emnapi/runtime@1.11.1)(@types/node@25.5.0)(@vercel/functions@3.5.1)(jiti@2.7.0)(rollup@4.60.0)(terser@5.43.1)(tsx@4.20.3)(yaml@2.9.0)
es-module-lexer: 2.1.0
estree-util-visit: 2.0.0
hast-util-to-html: 9.0.5
piccolore: 0.1.3
rehype-raw: 7.0.0
remark-gfm: 4.0.1
remark-smartypants: 3.0.2
source-map: 0.7.6
unist-util-visit: 5.1.0
vfile: 6.0.3
optionalDependencies:
'@astrojs/markdown-satteri': 0.3.4
transitivePeerDependencies:
- ...
So @astrojs/react@6.0.1 (which packages/website bumped from ^5.0.5 to ^6.0.1 in PR #1342) is the package that pulls in @vitejs/plugin-react@5.2.0 (NOT 6.0.4). The 6.0.4 is the spotlight direct dep.
So we have:
That's consistent. Both work, both target vite 8.
Let me also confirm shiki version.
shiki: ['3.13.0', '4.0.2'] @shikijs/transformers: ['3.13.0']
shiki@3.13.0:
resolution: {integrity: sha512-aZW4l8Og16CokuCLf8CF8kq+KK2yOygapU5m3+hoGw0Mdosc6fPitjM+ujYarppj5ZIKGyPDPP1vqmQhr+5/0g==}
shiki@4.0.2:
resolution: {integrity: sha512-eAVKTMedR5ckPo4xne/PjYQYrU3qx78gtJZ+sHlXEg5IHhhoQhMfZVzetTYuaJS0L2Ef3AcCRzCHV8T0WI6nIQ==}
engines: {node: '>=20'}
--
shiki@3.13.0:
dependencies:
'@shikijs/core': 3.13.0
'@shikijs/engine-javascript': 3.13.0
'@shikijs/engine-oniguruma': 3.13.0
'@shikijs/langs': 3.13.0
---
6204: shiki@4.0.2:
13999: shiki@4.0.2:
Both shiki@3.13.0 (spotlight direct devDep) AND shiki@4.0.2 (transitive from astro 7) coexist in the lockfile. Code uses shiki@3 (spotlight's devDep) — that's fine. Astro uses its own bundled shiki internally — also fine. No collision in namespace.
Now let me verify the dev/optional/timing settings on the lockfile:
autoInstallPeers: true — that might pull unwanted peer deps automatically. But it's the same setting as main.Now let me check whether app-builder-lib direct dep minimatch@10 chain actually still has dependencies on glob:
app-builder-lib@26.15.7:
resolution: {integrity: sha512-C7APoYISPExUmrEntNhDpz9Tccb4uWuEDfLaC0WPPc7/pwzz0WZGznCz/ycPfkkzw6tKOalceD8g6TgHmVz1QA==}
engines: {node: '>=14.0.0'}
peerDependencies:
dmg-builder: 26.15.7
electron-builder-squirrel-windows: 26.15.7
archiver-utils@2.1.0:
resolution: {integrity: sha512-bEL/yUb/fNNiNTuUz979Z0Yg5L+LzLxGJz8x79lYmR54fmTIb6ob/hNQgkQnIUDWIFjZVQwl9Xs356I6BAMHfw==}
engines: {node: '>= 6'}
archiver-utils@3.0.4:
resolution: {integrity: sha512-KVgf4XQVrTjhyWmx6cte4RxonPLR9onExufI1jhvw/MQ4BB6IsZD5gT8Lq+u/+pRkWna/6JoHpiQioaqFP5Rzw==}
engines: {node: '>= 10'}
archiver@5.3.2:
This is the resolution entry. Let me look at the dependency section (which appears later in the lockfile):
2963: app-builder-lib@26.15.7:
274: version: 26.15.7(electron-builder-squirrel-windows@24.13.3) 2967: dmg-builder: 26.15.7 2968: electron-builder-squirrel-windows: 26.15.7 3622: dmg-builder@26.15.7: 3690: electron-builder-squirrel-windows@24.13.3: 10024: app-builder-lib@26.15.7(dmg-builder@26.15.7)(electron-builder-squirrel-windows@24.13.3): 10045: dmg-builder: 26.15.7(electron-builder-squirrel-windows@24.13.3) 10049: electron-builder-squirrel-windows: 24.13.3(dmg-builder@26.15.7) 10827: dmg-builder@26.15.7(electron-builder-squirrel-windows@24.13.3): 10829: app-builder-lib: 26.15.7(dmg-builder@26.15.7)(electron-builder-squirrel-windows@24.13.3)
Good. The lockfile shows electron-builder-squirrel-windows@24.13.3 is what's actually installed (not 26.15.7). The peer of dmg-builder: 26.15.7 was satisfied with electron-builder-squirrel-windows: 24.13.3 (which is a downgrade but pnpm tolerated the peer mismatch because autoInstallPeers sometimes does). This isn't ideal but doesn't directly affect the macOS build.
Now let me look at the dmg-builder@26.15.7 to see what minimatch it pulls:
resolution: {integrity: sha512-rfo1YyAWO0L3cZLKCqKQiLYbW6ZXebRUfK0kWp4oXxO7dDFLrf7alRkWImNuXvZVQhs6Idzy++cwOk8I+xPDhw==}
doctrine@3.0.0:
resolution: {integrity: sha512-yS+Q5i3hBf7GBkd4KG8a7eBNNWNGLTaEwwYWUijIYM7zrlYDM0BFXHjjPWlWZ1Rg7UaddZeIDmi9jF3HmqiQ2w==}
engines: {node: '>=6.0.0'}
dom-accessibility-api@0.5.16:
resolution: {integrity: sha512-X7BJ2yElsnOJ30pZF4uIIDfBEVgF4XEBxL9Bxhy6dnrm5hkzqmsWHGTiHqRiITNhMyFLyAiWndIJP7Z1NTteDg==}
dom-accessibility-api@0.6.3:
resolution: {integrity: sha512-7ZgogeTnjuHbo+ct10G9Ffp0mif17idi0IyWNVA/wcwcm7NPOD/WEHVP3n7n3MhXqxoIYm8d6MuZohYWIZ4T3w==}
dom-serializer@2.0.0:
resolution: {integrity: sha512-wIkAryiqt/nV5EQKqQpo3SToSOV9J0DnbJqwK7Wv/Trc92zIAYZ4FlMu+JPFW1DfGFt81ZTCGgDEabffXeLyJg==}
domelementtype@2.3.0:
resolution: {integrity: sha512-OLETBj6w0OsagBwdXnPdN0cnMfF9opN69co+7ZrbfPGrdpPVNBUj02spi6B1N7wChLQiPn4CSH/zJvXw56gmHw==}
domhandler@5.0.3:
resolution: {integrity: ...
The dmg-builder@26.15.7 doesn't have direct deps shown yet. Let me look at the deps section:
dependencies:
path-type: 4.0.0
direction@2.0.1: {}
discontinuous-range@1.0.0: {}
dmg-builder@26.15.7(electron-builder-squirrel-windows@24.13.3):
dependencies:
app-builder-lib: 26.15.7(dmg-builder@26.15.7)(electron-builder-squirrel-windows@24.13.3)
builder-util: 26.15.3
fs-extra: 10.1.0
js-yaml: 4.3.0
transitivePeerDependencies:
- electron-builder-squirrel-windows
- supports-color
doctrine@3.0.0:
dependencies:
esutils: 2.0.3
dom-accessibility-api@0.5.16: {}
dom-accessibility-api@0.6.3: {}
dom-serializer@2.0.0:
dependencies:
domelementtype: 2.3.0
domhandler: 5.0.3
entities: 4.5.0
domelementtype@2.3.0: {}
domhandler@5.0.3:
dependencies:
domelementtype: 2.3.0
domutils@3.2.2:
dependencies:
dom-serializer: 2.0.0
domelementtype: 2.3.0
dmg-builder@26.15.7 uses app-builder-lib@26.15.7 which has minimatch@10.2.5 in its tree. The macOS DMG build path goes through dmg-builder → app-builder-lib → minimatch@10 → brace-expansion@2.x (forced) → TypeError.
This is confirmed catastrophic. PR #1341 will break pnpm build:mac.
Now let me also look at the actual pnpm install peer warnings or node-modules-strict issues. Let me check pnpm install output. But I can't easily run pnpm install here in this PR (modifies lockfile). I should be cautious.
Let me see if I can do a dry-run pnpm install:
@biomejs @eslint eslint @eslint-community eslint-plugin-react-hooks
M .lore.md ?? .opencode/ ?? packages/website/content.config.ts
/home/byk/Code/getsentry/spotlight 50016108 [security/deps-2026-07-28] /home/byk/.local/share/opencode/worktree/125e3ebeb747c35789e81a4b036ef58ca480e265/tidy-orchid 8e8fd0f6 [docs/turbo-json-env-config]
The current main worktree is on security/deps-2026-07-28 branch (50016108) — matching what user said. The other worktree is separate.
Status shows:
Now, "?? .opencode/" is untracked — likely the opencode runtime files. Let me NOT deal with that. Focus on correctness.
Let me try running pnpm install on the lockfile as-is to see warnings. But I'd be modifying the lockfile. Actually — since the user said "Currently NOT in rebase state — branches exist but have uncommitted/unmerged conflicts that will be re-applied to origin/main state", I think the safe thing to do is:
But this is heavy. ...
be-test cli-bump-031 lock1341.yaml lock1342.yaml lockmain.yaml Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-ubuntu--lv 99G 49G 46G 52% /tmp
fatal: git checkout: --detach does not take a path argument 'package.json'
Let me set up a scratch test. I'll use git worktree add to create a clean worktree to test PR #1341 without affecting the main working tree. Actually that's complex. Simpler: clone the repo to /tmp/opencode/scratch1341 and check out the PR branch.
Cloning into '/tmp/opencode/scratch1341'...
5001610 chore(deps): remediate 22 Dependabot alerts via pnpm overrides
/home/byk/.volta/bin/pnpm 9.15.9
Now let me run pnpm install in the scratch dir with --no-frozen-lockfile to verify whether it actually resolves cleanly. If it does, then we're done; if not, we'll see warnings/errors.
Scope: all 3 workspace projects Lockfile is up to date, resolution step is skipped Progress: resolved 1, reused 0, downloaded 0, added 0 Packages: +1425 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Progress: resolved 1425, reused 789, downloaded 0, added 0 Progress: resolved 1425, reused 1421, downloaded 0, added 14 Progress: resolved 1425, reused 1421, downloaded 0, added 158 Progress: resolved 1425, reused 1421, downloaded 0, added 336 Progress: resolved 1425, reused 1421, downloaded 0, added 571 Progress: resolved 1425, reused 1421, downloaded 0, added 722 Progress: resolved 1425, reused 1421, downloaded 0, added 723 Progress: resolved 1425, reused 1421, downloaded 0, added 875 Progress: resolved 1425, reused 1421, downloaded 0, added 901 Progress: resolved 1425, reused 1421, downloaded 0, added 1015 Progress: resolved 1425, reused 1421, downloaded 0, added 1157 Progress: resolved 1425, reused 1421, downloaded 0, added 1320 Progress: resolved ...
pnpm install succeeds cleanly with no peer warnings shown. That confirms at least the resolution is internally consistent. But the runtime issue with brace-expansion and minimatch@10 remains — that's a behavior bug, not a lockfile consistency issue.
Now let me actually verify the brace-expansion bug by running a test:
ERR: Cannot find module 'app-builder-lib/node_modules/minimatch' Require stack: - /tmp/opencode/scratch1341/[eval]
(no output)
node_modules/.pnpm/minimatch@10.2.5
node_modules/.pnpm/brace-expansion@2.1.3
minimatch path exists: true
node:internal/modules/cjs/loader:1424
throw err;
^
Error: Cannot find module 'minimatch'
Require stack:
- /tmp/opencode/scratch1341/[eval]
at Module._resolveFilename (node:internal/modules/cjs/loader:1421:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1059:19)
node:internal/modules/cjs/loader:1424
throw err;
^
Error: Cannot find module 'minimatch'
Require stack:
- /tmp/opencode/scratch1341/[eval]
at Module._resolveFilename (node:internal/modules/cjs/loader:1421:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1059:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1064:22)
at Module._load (node:internal/modules/cjs/loader:1227:37)
at TracingChannel.traceSync (node:diagnostics_channel:328:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:245:24)
at Module.require (node:internal/modules/cjs/loader:1504:12)
at require (node:internal/modules/helpers:152:16)
at [eval]:3:19
at runScriptInThisContext (node:internal/vm:219:10) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/tmp/opencode/scratch1341/[eval]' ]
}
Node.js v24.11.1
Hmm — minimatch not directly resolvable. Let me find a way:
brace-expansion minimatch
{
"author": "Isaac Z. Schlueter <i@izs.me> (http://blog.izs.me)",
"name": "minimatch",
"description": "a glob matcher in javascript",
"version": "10.2.5",
"repository": {
"type": "git",
"url": "git@github.com:isaacs/minimatch"
},
"main": "./dist/commonjs/index.js",
"types": "./dist/commonjs/index.d.ts",
"exports": {
"./package.json": "./package.json",
".": {
"import": {
"types": "./dist/esm/index.d.ts",
"default": "./dist/esm/index.js"
},
"require": {
"types": "./dist/commonjs/index.d.ts",
"default": "./dist/commonjs/index.js"
}
}
},
"files": [
minimatch loaded: function
CONFIRMED CRASH: (0 , brace_expansion_1.expand) is not a function
Stack: TypeError: (0 , brace_expansion_1.expand) is not a function
at braceExpand (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/dist/commonjs/index.js:157:41)
at Minimatch.braceExpand (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/dist/commonjs/index.js:898:40)
at Minimatch.make (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/dist/commonjs/index.js:268:41)
at new Minimatch (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/dist/commonjs/index.js:238:14)
CRASH CONFIRMED EXPERIMENTALLY:
TypeError: (0 , brace_expansion_1.expand) is not a function
at braceExpand (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/dist/commonjs/index.js:157:41)
at Minimatch.braceExpand (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/dist/commonjs/index.js:898:40)
at Minimatch.make (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/dist/commonjs/index.js:268:41)
at new Minimatch (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/dist/commonjs/index.js:238:14)
This is the EXACT bug from PR #1337 history, RE-INTRODUCED by PR #1341.
Now let me ALSO confirm the @xmldom/xmldom 0.9.10 mimeType issue at runtime:
node_modules/.pnpm/@xmldom+xmldom@0.9.10
node_modules/.pnpm/plist@3.1.1 node_modules/.pnpm/plist@3.1.0
node_modules/.pnpm/plist@3.1.0/node_modules/plist/dist/plist.js node_modules/.pnpm/plist@3.1.0/node_modules/plist/dist/plist-parse.js node_modules/.pnpm/plist@3.1.0/node_modules/plist/dist/plist-build.js node_modules/.pnpm/plist@3.1.0/node_modules/plist/lib/build.js node_modules/.pnpm/plist@3.1.0/node_modules/plist/lib/parse.js
dist examples History.md index.js lib LICENSE Makefile package.json README.md Testing plist@3.1.0 + @xmldom/xmldom@0.9.10... CRASH: DOMParser.parseFromString: the provided mimeType "undefined" is not valid.
SECOND CRASH CONFIRMED:
CRASH: DOMParser.parseFromString: the provided mimeType "undefined" is not valid.
PR #1341 ALSO breaks plist parsing in app-builder-lib chain. TWO CRITICAL runtime crashes confirmed.
Now let me also quickly verify the PR #1342 by doing the same test in a separate scratch. PR #1342 inherits all of #1341's overrides plus vite 8. The same crashes would occur. Let me run install on PR #1342 too:
Cloning into '/tmp/opencode/scratch1342'...
Scope: all 3 workspace projects Lockfile is up to date, resolution step is skipped Progress: resolved 1, reused 0, downloaded 0, added 0 Packages: +1398 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Progress: resolved 1398, reused 333, downloaded 0, added 0 Progress: resolved 1398, reused 1247, downloaded 0, added 0 Progress: resolved 1398, reused 1393, downloaded 0, added 60 Progress: resolved 1398, reused 1393, downloaded 0, added 163 Progress: resolved 1398, reused 1393, downloaded 0, added 316 Progress: resolved 1398, reused 1393, downloaded 0, added 464 Progress: resolved 1398, reused 1393, downloaded 0, added 695 Progress: resolved 1398, reused 1393, downloaded 0, added 735 Progress: resolved 1398, reused 1393, downloaded 0, added 736 Progress: resolved 1398, reused 1393, downloaded 0, added 866 Progress: resolved 1398, reused 1393, downloaded 0, added 986 Progress: resolved 1398, reused 1393, downloaded 0, added 1133 Progress: resolved 1398, ...
PR #1342 also installs cleanly. Now let me verify the same brace-expansion / xmldom bugs are present in PR #1342 (they should be, since both use the same overrides):
CONFIRMED CRASH: (0 , brace_expansion_1.expand) is not a function
node_modules/.pnpm/@xmldom+xmldom@0.9.10
{
"name": "@xmldom/xmldom",
"version": "0.9.10",
PR #1342 has the same crash. Both PRs re-introduce the bugs that PR #1337 fixed.
Now let me also try to build the electron app and run the website build to see what else breaks. The user mentioned to look for additional ESM/CJS interop issues:
failed to load config from /tmp/opencode/scratch1342/packages/spotlight/vite.config.dev.ts
error during build:
Error: Build failed with 1 error:
[31m[UNRESOLVED_ENTRY] [0mCannot resolve entry module vite.config.dev.ts.
at aggregateBindingErrorsIntoJsError (file:///tmp/opencode/scratch1342/node_modules/.pnpm/rolldown@1.1.5/node_modules/rolldown/dist/shared/error-BHRSI0R7.mjs:48:18)
at unwrapBindingResult (file:///tmp/opencode/scratch1342/node_modules/.pnpm/rolldown@1.1.5/node_modules/rolldown/dist/shared/error-BHRSI0R7.mjs:18:128)
at #build (file:///tmp/opencode/scratch1342/node_modules/.pnpm/rolldown@1.1.5/node_modules/rolldown/dist/shared/rolldown-build-CtPvmZgJ.mjs:3276:34)
at async bundleConfigFile (file:///tmp/opencode/scratch1342/node_modules/.pnpm/vite@8.1.5_@types+node@22.15.28_esbuild@0.28.1_jiti@2.7.0_terser@5.43.1_tsx@4.20.3_yaml@2.8.3/node_modules/vite/dist/node/chunks/node.js:36132:17)
at async bundleAndLoadConfigFile ...
That tried to build vite.config.dev.ts which doesn't exist. Let me find the actual build script:
/tmp/opencode/scratch1342/packages/spotlight/vite.config.base.ts /tmp/opencode/scratch1342/packages/spotlight/vite.dev.config.ts /tmp/opencode/scratch1342/packages/spotlight/vite.electron.config.ts /tmp/opencode/scratch1342/packages/spotlight/vite.node.config.ts /tmp/opencode/scratch1342/packages/spotlight/vitest.cli.config.ts /tmp/opencode/scratch1342/packages/spotlight/vitest.config.ts /tmp/opencode/scratch1342/packages/spotlight/vite.ui.config.ts
"build": "vite build --config vite.node.config.ts && vite build --config vite.ui.config.ts && npm run build:sea && npm run build:electron",
"build:sea": "fossilize -m dist/ui/manifest.json -o spotlight dist/run.js",
"build:watch": "vite build --watch",
"build:electron": "vite build --config vite.electron.config.ts",
"build:mac": "./electron-builder.cjs",
"preview": "vite preview",
Let me also look at potential build:mac issues by trying just the build:mac step directly. But first let me actually try the website build which is one of the things PR #1342 explicitly claims to fix.
12:41:49 ├─ /404.htmlEntry docs → 404 was not found. (+55ms) 12:41:49 ├─ /index.html (+903ms) 12:41:50 ├─ /docs/index.html (+32ms) 12:41:50 ├─ /docs/about/index.html (+88ms) 12:41:50 ├─ /docs/architecture/index.html (+26ms) 12:41:50 ├─ /docs/cli/index.html (+108ms) 12:41:50 ├─ /docs/cli/reference/index.html (+31ms) 12:41:50 ├─ /docs/cli/run/index.html (+56ms) 12:41:50 ├─ /docs/cli/tail/index.html (+36ms) 12:41:50 ├─ /docs/contribute/index.html (+16ms) 12:41:50 ├─ /docs/contribute/commits/index.html (+15ms) 12:41:50 ├─ /docs/contribute/development/index.html (+12ms) 12:41:50 ├─ /docs/contribute/docs/index.html (+11ms) 12:41:50 ├─ /docs/contribute/releases/index.html (+12ms) 12:41:50 ├─ /docs/desktop-app/index.html (+75ms) 12:41:50 ├─ /docs/getting-started/index.html (+76ms) 12:41:50 ├─ /docs/mcp/index.html (+59ms) 12:41:50 ├─ /docs/mcp/tools/index.html (+21ms) 12:41:50 ├─ /docs/mcp/workflows/index.html (+22ms) 12:41:50 ├─ ...
Website builds cleanly! 29 pages built in 11s. PR #1342's astro 7 + vite 8 + starlight 0.41 migration is OK at the website level.
Now let me also test that vite-plugin-svgr actually transforms SVGs correctly. Let me try a small UI build test:
dist/ui/assets/css.js 49.45 kB │ gzip: 12.15 kB │ map: 60.61 kB dist/ui/assets/imba.js 50.30 kB │ gzip: 9.67 kB │ map: 68.07 kB dist/ui/assets/everforest-dark.js 54.13 kB │ gzip: 8.59 kB │ map: 68.26 kB dist/ui/assets/everforest-light.js 54.13 kB │ gzip: 8.59 kB │ map: 68.26 kB dist/ui/assets/r.js 56.17 kB │ gzip: 15.44 kB │ map: 68.19 kB dist/ui/assets/html.js 57.67 kB │ gzip: 11.97 kB │ map: 72.98 kB dist/ui/assets/markdown.js 59.71 kB │ gzip: 5.86 kB │ map: 82.32 kB dist/ui/assets/python.js 70.32 kB │ gzip: 9.29 kB │ map: 95.23 kB dist/ui/assets/c.js 72.54 kB │ gzip: 10.75 kB │ map: 95.37 kB dist/ui/assets/less.js 98.00 kB │ gzip: 15.05 kB │ map: ...
UI build succeeds in 5s. vite-plugin-svgr (31% of build time, but no errors). 27 files with ReactComponent imports compile fine.
Let me also verify by checking if any of the compiled output has ReactComponent:
dist/ui/assets/css.js dist/ui/assets/less.js dist/ui/assets/react-instance.js
dist/ui/assets/react-instance.js:3 dist/ui/assets/src.js:1
The SVG icons (CheckIcon, etc.) are in the compiled bundles. Good — vite-plugin-svgr transform works.
Now let me also verify whether electron-builder can be invoked:
Testing fileMatcher from app-builder-lib...
node:internal/modules/cjs/loader:1424
throw err;
^
Error: Cannot find module './node_modules/.pnpm/app-builder-lib@26.15.7_dmg-builder@26.15.7_electron-builder-squirrel-windows@24.13.3/node_modules/app-builder-lib/out/fileMatcher'
Require stack:
- /tmp/opencode/scratch1341/packages/spotlight/[eval]
at Module._resolveFilename (node:internal/modules/cjs/loader:1421:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1059:19)
Loading app-builder-lib and testing glob filtering...
node:internal/modules/cjs/loader:1424
throw err;
^
Error: Cannot find module 'app-builder-lib/out/fileMatcher'
Require stack:
- /tmp/opencode/scratch1341/packages/spotlight/[eval]
at Module._resolveFilename (node:internal/modules/cjs/loader:1421:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1059:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1064:22)
at Module._load (node:internal/modules/cjs/loader:1227:37)
at TracingChannel.traceSync (node:diagnostics_channel:328:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:245:24)
at Module.require (node:internal/modules/cjs/loader:1504:12)
at require (node:internal/modules/helpers:152:16)
at [eval]:5:25
at runScriptInThisContext (node:internal/vm:219:10) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/tmp/opencode/scratch1341/packages/spotlight/[eval]' ]
Let me find the right way to load app-builder-lib from the scratch repo:
/tmp/opencode/scratch1341/node_modules/.pnpm/app-builder-lib@26.15.7_dmg-builder@26.15.7_electron-builder-squirrel-windows@24.13.3
node_modules/.pnpm/app-builder-lib@26.15.7_dmg-builder@26.15.7_electron-builder-squirrel-windows@24.13.3/node_modules/app-builder-lib/out/fileMatcher.js
cwd: /tmp/opencode/scratch1341 CRASH: Cannot find module 'app-builder-lib' Require stack: - /tmp/opencode/scratch1341/[eval]
Loading from: /tmp/opencode/scratch1341/node_modules/.pnpm/app-builder-lib@26.15.7_dmg-builder@26.15.7_electron-builder-squirrel-windows@24.13.3/node_modules/app-builder-lib app-builder-lib loaded: object FileMatcher: undefined CRASH: FileMatcher is not a constructor
Loading from: /tmp/opencode/scratch1341/node_modules/.pnpm/app-builder-lib@26.15.7_dmg-builder@26.15.7_electron-builder-squirrel-windows@24.13.3/node_modules/app-builder-lib/out/fileMatcher.js fileMatcher loaded: [ 'excludedNames', 'excludedExts', 'FileMatcher', 'getMainFileMatchers', 'getNodeModuleFileMatcher', 'getFileMatchers', 'copyFiles' ]
FileMatcher: function getFileMatchers: function CRASH: macroExpander is not a function
Trying new FileMatcher directly...
CRASH: macroExpander is not a function
Stack: TypeError: macroExpander is not a function
at new FileMatcher (/tmp/opencode/scratch1341/node_modules/.pnpm/app-builder-lib@26.15.7_dmg-builder@26.15.7_electron-builder-squirrel-windows@24.13.3/node_modules/app-builder-lib/src/fileMatcher.ts:57:34)
at [eval]:8:13
at runScriptInThisContext (node:internal/vm:219:10)
at node:internal/process/execution:451:12
NEW BUG: macroExpander is not a function! This is another regression. Let me check the macroExpander source.
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.FileMatcher = exports.excludedExts = exports.excludedNames = void 0;
exports.getMainFileMatchers = getMainFileMatchers;
exports.getNodeModuleFileMatcher = getNodeModuleFileMatcher;
exports.getFileMatchers = getFileMatchers;
exports.copyFiles = copyFiles;
const builder_util_1 = require("builder-util");
const promises_1 = require("fs/promises");
const minimatch_1 = require("minimatch");
const path = require("path");
const filter_1 = require("./util/filter");
// https://github.com/electron-userland/electron-builder/issues/733
const minimatchOptions = { dot: true };
// noinspection SpellCheckingInspection
exports.excludedNames = ".git,.hg,.svn,CVS,RCS,SCCS," +
"__pycache__,.DS_Store,thumbs.db,.gitignore,.gitkeep,.gitattributes,.npmignore," +
".idea,.vs,.flowconfig,.jshintrc,.eslintrc,.circleci," +
...
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.expandMacro = expandMacro;
const builder_util_1 = require("builder-util");
function expandMacro(pattern, arch, appInfo, extra = {}, isProductNameSanitized = true) {
if (arch == null) {
pattern = pattern
// tslint:disable-next-line:no-invalid-template-strings
.replace("-${arch}", "")
// tslint:disable-next-line:no-invalid-template-strings
.replace(" ${arch}", "")
// tslint:disable-next-line:no-invalid-template-strings
.replace("_${arch}", "")
// tslint:disable-next-line:no-invalid-template-strings
.replace("/${arch}", "");
}
return pattern.replace(/\${([_a-zA-Z./*+]+)}/g, (match, p1) => {
switch (p1) {
case "productName":
return isProductNameSanitized ? appInfo.sanitizedProductName : appInfo.productName;
case "arch":
if (arch ...
(no output)
OK the macroExpander crash is a separate bug — caused by passing undefined as 3rd arg. The FileMatcher constructor signature is constructor(from, to, macroExpander, patterns) — so my test passed patterns as 4th arg but macroExpander as undefined. Let me re-test with proper arguments.
The actual crash will be minimatch.expand is not a function when constructing with brace patterns. Let me verify with a more accurate test:
FileMatcher created without crash. Patterns: [ '{docs,src}/**/*' ]
matches /tmp/srcdir/docs/x.txt: false
CRASH: m.getFilter is not a function
Stack (first 7): TypeError: m.getFilter is not a function
at [eval]:14:20
at runScriptInThisContext (node:internal/vm:219:10)
at node:internal/process/execution:451:12
at [eval]-wrapper:6:24
at runScriptInContext (node:internal/process/execution:449:60)
at evalFunction (node:internal/process/execution:283:30)
Hmm — getFilter doesn't exist on FileMatcher. Let me look for createFilter.
createFilter() {
return (0, filter_1.createFilter)(this.from, parsedPatterns, this.excludePatterns);
return await (0, builder_util_1.copyDir)(matcher.from, matcher.to, { filter: matcher.createFilter(), transformer, isUseHardLink: isUseHardLink ? builder_util_1.USE_HARD_LINKS : null });
FileMatcher created
CRASH: (0 , brace_expansion_1.expand) is not a function
Stack (first 7): TypeError: (0 , brace_expansion_1.expand) is not a function
at braceExpand (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/src/index.ts:341:16)
at Minimatch.braceExpand (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/src/index.ts:1243:23)
at Minimatch.make (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/src/index.ts:480:37)
at new Minimatch (/tmp/opencode/scratch1341/node_modules/.pnpm/minimatch@10.2.5/node_modules/minimatch/src/index.ts:444:10)
at FileMatcher.computeParsedPatterns (/tmp/opencode/scratch1341/node_modules/.pnpm/app-builder-lib@26.15.7_dmg-builder@26.15.7_electron-builder-squirrel-windows@24.13.3/node_modules/app-builder-lib/src/fileMatcher.ts:100:29)
at FileMatcher.createFilter ...
END-TO-END CRASH CONFIRMED:
CRASH: (0 , brace_expansion_1.expand) is not a function
at braceExpand (minimatch@10.2.5/src/index.ts:341:16)
at Minimatch.braceExpand (minimatch@10.2.5/src/index.ts:1243:23)
at Minimatch.make (minimatch@10.2.5/src/index.ts:480:37)
at new Minimatch (minimatch@10.2.5/src/index.ts:444:10)
at FileMatcher.computeParsedPatterns (app-builder-lib/src/fileMatcher.ts:100:29)
at FileMatcher.createFilter (app-builder-lib/src/fileMatcher.ts:114:10)
This is the EXACT, FULL runtime failure: new FileMatcher(...) → createFilter() → new Minimatch(pattern with braces) → braceExpand() → minimatch@10 requires brace-expansion@5's named export → TypeError.
This means PR #1341 will 100% break pnpm build:mac (and any electron-builder invocation that creates a FileMatcher with a brace-containing pattern, which is the common case for file globs in mac DMG/zip building).
Now let me look at one final thing — the @sentry/starlight-theme@0.3.0 ...
(no output)
peer: {'@astrojs/starlight': '>=0.39.0'}
@sentry/starlight-theme@0.3.0 peer is >=0.39.0 for @astrojs/starlight. PR #1342 bumps starlight to ^0.41.5 which satisfies >=0.39.0. ✓ no peer warning.
Wait, also need to check @astrojs/vercel@^11.0.3 peer — astro peer.
peer: {'astro': '^7.0.0'}
peer: {'react': '^17.0.2 || ^18.0.0 || ^19.0.0', 'react-dom': '^17.0.2 || ^18.0.0 || ^19.0.0', '@types/react': '^17.0.50 || ^18.0.21 || ^19.0.0', '@types/react-dom': '^17.0.17 || ^18.0.6 || ^19.0.0'}
peer: {'astro': '^7.0.2', '@astrojs/markdown-remark': '^7.2.0'}
Peers all check out:
Now let me check the @tailwindcss/vite catalog bump. The catalog bumped to ^4.3.3 but the @tailwindcss/vite from astro 7 might require specific version. Wait actually the catalog is ^4.3.3 and the resolved version from lockfile:
@tailwindcss/vite: ['4.3.3'] tailwindcss: ['4.1.11', '4.3.3'] @vitejs/plugin-react: ['5.2.0', '6.0.4'] vite-plugin-svgr: ['5.2.0'] @astrojs/mdx: ['7.0.4']
peer: {'vite': '^8.0.0', '@rolldown/plugin-babel': '^0.1.7 || ^0.2.0', 'babel-plugin-react-compiler': '^1.0.0'}
@vitejs/plugin-react@6.0.4 peer: vite ^8.0.0 — and vite override resolves to vite@8.1.5 ✓
Note: peer babel-plugin-react-compiler: ^1.0.0 — let me see if this is autoinstalled:
(no output)
node:internal/modules/cjs/loader:1424 throw err; ^ Error: Cannot find module 'vite-plugin-svgr'
babel-plugin-react-compiler is not autoinstalled (autoInstallPeers: true is the setting but the peer might be optional). Let me check if it shows up as a peer warning during install:
(no output)
No peer warnings from pnpm install. So peers are all satisfied at install time. The fact that the UI build worked confirms this. (the babel-plugin-react-compiler is probably optional or otherwise OK)
Let me also check that there's no specific ESM/CJS issue not caught by the build:
dist/node_modules/.pnpm/zod@4.1.13/node_modules/zod/v4/core/checks.js 11.47 kB │ gzip: 2.29 kB │ map: 28.15 kB dist/node_modules/.pnpm/fast-uri@4.1.1/node_modules/fast-uri/index.js 11.98 kB │ gzip: 3.18 kB │ map: 19.96 kB dist/server/mcp/mcp.js 12.94 kB │ gzip: 4.35 kB │ map: 18.22 kB dist/server/formatters/md/event.js 13.82 kB │ gzip: 4.21 kB │ map: 26.53 kB dist/node_modules/.pnpm/fast-uri@4.1.1/node_modules/fast-uri/lib/utils.js 14.66 kB │ gzip: 4.01 kB │ map: 23.43 ...
Spotlight node build also OK (9.34s). The vite 8 + plugin-react 6 + svgr 5 combination builds cleanly.
Now let me also verify PR #1342's package version regression to make sure it really reverts 4.11.8:
"version": "4.11.7",
"version": "4.11.8",
CONFIRMED: Both PRs revert the spotlight package version from 4.11.8 to 4.11.7 — a publication rollback of an already-released version. After merge, Craft release tooling would re-publish 4.11.7, producing a duplicate version. This is a behavior break for @spotlightjs/spotlight consumers on 4.11.8.
Now let me also check whether the website also has version issues (it likely doesn't, since it's private):
"version": "0.0.1", --- "version": "0.0.1",
Website version is 0.0.1 private — no issue. The spotlight version is the only publication concern.
Now let me also check the .lore.md note mentions "as 2.1.2 → reverts to exact 2.1.2" or similar. The .lore.md update in PR #1341/#1342 is essentially identical, adding entries about @xmldom/xmldom and brace-expansion 5.0.8 etc. These ARE the gotchas. Seer comments in PR #1341 flagged exactly these issues.
Also, one quick check — what does the PR name say and what does it NOT mention:
But the relevant dependencies that become 22 are spread across the lot. The actual closed count I calculated: ~21 (if my count is right). Let me verify more precisely by writing a script that counts specific alerts resolved per closure. ...
Now I have everything I need. Let me do a final check on the PR #1341's @hono/node-server direct dep range downgrade.
latest 2.x: 2.0.12 2.0.5: published=11.14.1, _id exists=True 2.0.10: published=?, _id exists=True 2.0.12: published=?, _id exists=True
state: open created: 2026-07-28T12:07:16Z mergeable: False
Total comments: 2 FILE=package.json line=57 body=**Bug:** The open-ended pnpm override for `@xmldom/xmldom` resolves to a version with a breaking API change, which will cause the `build:mac` command to fail.<br><sub>Severity: CRITICAL</sub> <!-- BUG FILE=package.json line=47 body=**Bug:** The pnpm override for `brace-expansion` forces an incompatible major version (`2.x`), breaking a dependency (`minimatch@10.x`) that requires version `5.x` and causing the macOS build to fail.
Seer's comments on PR #1341:
package.json:57 — @xmldom/xmldom open-ended resolves to breaking API change → build:mac fails. CRITICAL.package.json:47 — brace-expansion forces 2.x → minimatch@10 needs 5.x → build:mac fails. CRITICAL.Both comments are CORRECT and CONFIRMED by my empirical reproduction in /tmp/opencode/scratch1341.
PR is also marked mergeable: false — there are merge conflicts.
Let me also do a final sanity check on the diff vs closure mapping and any missed details. Now let me write the comprehensive review.
Looking at lockfile comparisons one more time:
Plus PR #1342 has astro 7→vite 8→plugin-react 6 cascade issues that might add MORE problems.
Let me also look at one final issue — the .vite-inspect/ directory in packages/website/. It's untracked in main but the user mentioned branches are not in "rebase state". ...
I have empirical evidence for every critical claim. Here is the adversarial review.
1. [CRITICAL] Re-introduces the exact brace-expansion regression that PR #1337 fixed (build:mac will throw at runtime)
Evidence:
"brace-expansion": ">=2.1.0 <3" (package.json:47)50016108): brace-expansion: [2.1.3] (single version — all brace-expansion installs forced to 2.1.3)minimatch@10.2.5 is STILL in the lockfile despite the "glob@>=13.0.0": "10.4.5" downforce. Verified: minimatch@10.2.5 lines 5216 and 12935 of /tmp/opencode/lock1341.yaml. Source: app-builder-lib@26.15.7 directly depends on minimatch: "^10.2.5" (registry.npmjs.org/app-builder-lib/26.15.7)./tmp/opencode/scratch1341 after pnpm install:
$ node -e "const m=new (require('minimatch').Minimatch)('foo/{a,b}'); m.braceExpand()"TypeError: (0 , brace_expansion_1.expand) is not a function at braceExpand (.../minimatch@10.2.5/.../dist/commonjs/index.js:157:41)
module.exports = expandTop; (no named expand). Unpkg confirms brace-expansion@5.0.8 CJS does exports.expand = expand;.TypeError: (0 , brace_expansion_1.expand) is not a function at braceExpand (.../minimatch@10.2.5/.../src/index.ts:341:16) at Minimatch.braceExpand (.../minimatch@10.2.5/.../src/index.ts:1243:23) at new Minimatch (.../minimatch@10.2.5/.../src/index.ts:444:10) at FileMatcher.computeParsedPatterns (.../app-builder-lib@26.15.7/.../src/fileMatcher.ts:100:29) at FileMatcher.createFilter (.../app-builder-lib@26.15.7/.../src/fileMatcher.ts:114:10)
"glob@>=13.0.0": "10.4.5" downforce is incomplete — it eliminates the glob@13 → minimatch@10 path, but does ...<observations> Date: Jul 28, 2026 * 🟡 (12:45) Agent retrieved Seer's PR #1341 comments via tool: 2 total comments at package.json:57 (`@xmldom/xmldom` open-ended → build:mac fails, CRITICAL) and package.json:47 (`brace-expansion` forces 2.x → minimatch@10 needs 5.x → build:mac fails, CRITICAL). PR state: open, created 2026-07-28T12:07:16Z, mergeable=false * 🟡 (12:45) Agent retrieved version met…
<observations> Date: Jul 28, 2026 * 🟡 (12:40) Agent confirmed brace-expansion crash EXPERIMENTALLY in scratch1341: `TypeError: (0 , brace_expansion_1.expand) is not a function` at `minimatch@10.2.5/dist/commonjs/index.js:157:41` → `Minimatch.braceExpand` (line 898) → `Minimatch.make` (line 268) → `new Minimatch` (line 238). Test sequence: load minimatch from `node_modules/.pnpm/minimatch@10.2.5/…
Date: Jul 28, 2026 * 🟡 (12:37) Agent traced app-builder-lib@26 minimatch usage via cached source: `out/util/filter.js` uses `minimatchAll` (calls `Minimatch.match()`), `out/fileMatcher.js:69,76,82` constructs `new Minimatch(pattern, minimatchOptions)` directly. Both paths trigger minimatch's brace expansion during construction. app-builder-lib@26.8.1 cached at `/home/byk/.bun/install/cache/app-b…
<observations> Date: Jul 28, 2026 * 🟡 (12:34) Agent inspected vite-plugin-svgr@5.2.0 source: DEFAULT include is `**/*.svg?react` (NOT `**/*.svg`); uses `createFilter` from `@rollup/pluginutils@^5.3.0`; peer dependency vite ">=3.0.0". Plugin code dynamically imports @svgr/core + @svgr/plugin-jsx, then conditionally uses `transformWithOxc` (when `this.meta.rolldownVersion != null`) or `transformWi…
<observations> Date: Jul 28, 2026 * 🟡 (12:34) Agent confirmed plist@3.1.0 source line 66 calls `new DOMParser().parseFromString(xml)` with NO mimeType argument (only the XML source passed). This is the exact call site that broke when paired with @xmldom/xmldom@0.9.10's strict mimeType validation * 🟡 (12:34) Agent conclusion: PR #1341 re-introduces the exact bug fixed by PR #1337 — plist@3.1.0 +…
Date: Jul 28, 2026 * 🟡 (12:32) Agent confirmed minimatch@10.2.5 source line 155 calls `brace_expansion_1.expand` as a named export: `return (0, brace_expansion_1.expand)(pattern, ...)` * 🟡 (12:32) Agent confirmed brace-expansion@5.0.7 (and 5.0.8) uses `./dist/commonjs/index.js` with `exports.expand = expand` (named export). CVE-2026-14257 fix added `EXPANSION_MAX_LENGTH` constant (100k characte…
<observations> Date: Jul 28, 2026 * 🟡 (12:32) Agent cross-reference of `pnpm-lock.yaml` transitive dep snapshots: MAIN has svgo 4.0.1 + glob 13.0.6 + brace-expansion 1.1.16/2.1.2/5.0.7 + @xmldom/xmldom 0.8.13 + plist 3.1.0/3.1.1 + app-builder-lib 24.13.3/26.15.7 + electron-builder 26.15.7 + electron-builder-squirrel-windows 24.13.3. PR #1341 and PR #1342 both: svgo 4.0.2, glob 10.4.5/10.5.0/7.2.…
Date: Jul 28, 2026 * 🟡 (12:31) Agent reviewing PR #1341 and PR #1342 — found CRITICAL finding: both branches roll back spotlight package version from `4.11.8` (current main, from commit 89131421 "release: 4.11.8") to `4.11.7` (released in commit d6c318cc). Likely rebase artifact since branches predate 4.11.8 release. Risk: Craft release workflow would re-publish 4.11.7 (duplicate), and consumers…
<observations> Date: Jul 28, 2026 * 🟡 (12:31) vite-plugin-inspect version inventory confirmed: 3 versions coexist in repo node_modules — 0.7.42 (original, vite@7.3.5 context, under packages/website direct dep `^0.7.42`); 11.4.1 (vite@8.1.5 context, transitive from some peer chain); 12.0.2 (newer, `@antfu-collective/vite-plugin-inspect` ownership, published for vite 8). The 11.4.1 trace comes fro…
<observations> Date: Jul 28, 2026 * 🟡 (12:29) Resolution data captured for 24 packages × 3 lockfiles (MAIN/PR1341/PR1342). Key versions: MAIN has @xmldom/xmldom@0.8.13, react-router-dom@7.17.0, sharp@[0.34.5, 0.35.0], vite@[6.4.3, 7.3.5], brace-expansion@[1.1.16, 2.1.2, 5.0.7], glob@13.0.6, @hono/node-server@[1.19.15, 2.0.10] * 🟡 (12:29) PR #1341 resolves: @xmldom/xmldom@0.9.10 (BROKEN — open-e…
<observations> Date: Jul 28, 2026 * 🟡 (12:28) Assistant attempted to read three lockfile sections (MAIN, PR1341, PR1342) but output was truncated/empty initially * 🟡 (12:28) After retry, yaml.safe_load succeeded: MAIN has 1606 packages, PR1341 has 1549 packages, PR1342 has 1547 packages * 🟡 (12:28) Initial version-check query for 17 packages (brace-expansion, glob, @xmldom/xmldom, tar, js-yaml…
Date: Jul 28, 2026 * 🟡 (12:28) User provided tool result containing three lockfile sections (lockmain.yaml, lock1341.yaml, lock1342.yaml) which appeared truncated/empty in the output. Assistant reasoning: output seemed truncated; pivoting to simpler approach
Date: Jul 28, 2026 * 🟡 (12:27) User provided tool result: lockfileVersion: 9.0, Total packages: 1549 (in one lockfile comparison context) * 🟡 (12:27) User provided tool result showing file line counts: lock1341.yaml=14848 lines, lock1342.yaml=14826 lines, lockmain.yaml=15408 lines — all in /tmp/opencode/ * 🟡 (12:27) Assistant reasoning: initial extraction via yaml.safe_load got truncated by no…
<observations> Date: Jul 28, 2026 * 🔴 (12:27) User-stated knowledge re-verified in PR #1341 (security/deps-2026-07-28): scripts/notarize.cjs is dead code in getsentry/spotlight — electron-builder notarizes internally via afterSign hook using @electron/notarize, never calls scripts/notarize.cjs. * 🔴 (12:27) Assistant identified CRITICAL regression in PR #1341: `@xmldom/xmldom` override was rever…
Date: Jul 28, 2026 * 🔴 (12:27) User stated scripts/notarize.cjs is dead code in getsentry/spotlight — electron-builder notarizes internally via its afterSign hook using @electron/notarize, never calls scripts/notarize.cjs. When debugging Apple notarization failures, check build.yml's Apple key decode/export steps and electron-builder's config, not this file. * 🔴 (12:27) User stated they always …
<observations> Date: Jul 28, 2026 * 🟡 (12:27) Tool result: 28 open Dependabot alerts extracted with full details (id, severity, package, scope, vulnerable range, patched version, manifest). Alert IDs: #323, #322, #321, #320, #319, #318, #317, #316, #315, #314, #313, #312, #311, #305, #304, #303, #302, #301, #300, #299, #298, #297, #296, #295, #293, #292, #291, #290. Gaps in numbering observed: #…
Date: Jul 28, 2026 * 🟡 (12:27) Tool result: Python script attempted to parse alert JSON but threw KeyError at line 12: `KeyError: 'vulnerable_version_range'`. Output truncated after "Total open alerts: 28" — meaning 28 open alerts exist in the repo's dependabot alerts. * 🟡 (12:27) Tool result: fetch from getsentry/spotlight fetched branch `security/deps-2026-07-28` and `fix/astro-7-vite-8-migra…
Date: Jul 28, 2026 * 🟡 (12:27) PR #1341 file stats: 4 files changed — .lore.md (+79/-7), package.json (+12/-6), packages/spotlight/package.json (+2/-2), pnpm-lock.yaml (+304/-695). headRefOid: 50016108d56cbf3ff88e51b2d11e4273212e7e1b. State: OPEN. * 🟡 (12:27) PR #1342 file stats: 9 files changed — .lore.md (+79/-7), package.json (+13/-8), packages/spotlight/package.json (+4/-4), packages/spotli…
<observations> Date: Jul 28, 2026 * 🟡 (12:25) User requested adversarial, evidence-based correctness review of two PRs in getsentry/spotlight (PR #1341 and PR #1342). Both PRs close Dependabot alerts in pnpm-lock.yaml via pnpm overrides and direct dep bumps. Review must be READ-ONLY, skeptical, and trace every claim to actual evidence (lockfile, source code, registry metadata). CORRECTNESS only …