You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Out-of-scope finding, recorded while doing #4006 (PR #4539 — the build tsconfigs of fields / plugin-editor). It turned up on a plain ls of the package root, not from any measurement in that card, and it is not fixed there.
Labelled finding, not queued. Nothing is broken today: builds and tests are green, and the file cannot affect either (see below). This is repo hygiene plus a missing ignore rule.
Fact
One tracked file in the whole repo matches Vite's temp-config naming:
4368 bytes. Added in 39b03a1 ("Add CanvasDesigner mode with free-form absolute positioning", 2026-01-15, copilot-swe-agent[bot]) — swept in by a broad git add, not authored.
It is the bundled form Vite writes next to a config while loading it, and it is frozen at the moment it was captured: it still carries absolute paths from a CI runner (/home/runner/work/objectui/objectui/node_modules/.pnpm/...), and it pins vite@5.4.21, @vitejs/plugin-react@4.7.0, vite-plugin-dts@3.9.1. The repo is now on vite@8.2.1 / plugin-react@6.0.5 / vite-plugin-dts@5.0.3, so the content is about seven months and three majors stale.
It also embeds a snapshot of the config as it was then, which no longer matches vite.config.ts: the live config aliases twelve @object-ui/* specifiers to sibling sources and passes compilerOptions / aliasesExclude to the dts plugin; the frozen copy has a single @ alias and a bare dts({ insertTypesEntry, include }).
Why it is inert
Vite does not load it. Config resolution looks for vite.config.{js,mjs,cjs,ts,mts,cts}; this basename is vite.config.ts.timestamp-..., which matches none of them. vite.config.ts is what is read.
So the cost is a reader stumbling on a stale second copy of a config and having to work out which one is live — plus the ignore gap below, which is the part that can recur.
The reusable half: .gitignore has no rule for it
$ git check-ignore -v packages/plugin-editor/vite.config.ts.timestamp-...mjs
(no output — NOT ignored)
Vite writes these on every config load and normally removes them, but a crashed or killed process leaves one behind; nothing stops the next broad git add from committing it again. A single root rule would close that:
*.timestamp-*.mjs
Adjacent but distinct from #3592 (__dirname in 28 vite/vitest configs) — that one is about the live configs' contents, this one is about a stale artifact sitting beside one, so it is filed separately rather than as a comment there.
Suggested shape, if it is ever picked up
Delete the file and add the ignore rule; both are one-liners and belong together, since deleting without the rule leaves the recurrence path open. Worth confirming first that nothing references the path (a grep at the time of this filing finds no reference).
Out-of-scope finding, recorded while doing #4006 (PR #4539 — the build tsconfigs of
fields/plugin-editor). It turned up on a plainlsof the package root, not from any measurement in that card, and it is not fixed there.Labelled
finding, not queued. Nothing is broken today: builds and tests are green, and the file cannot affect either (see below). This is repo hygiene plus a missing ignore rule.Fact
One tracked file in the whole repo matches Vite's temp-config naming:
4368 bytes. Added in 39b03a1 ("Add CanvasDesigner mode with free-form absolute positioning", 2026-01-15,
copilot-swe-agent[bot]) — swept in by a broadgit add, not authored.It is the bundled form Vite writes next to a config while loading it, and it is frozen at the moment it was captured: it still carries absolute paths from a CI runner (
/home/runner/work/objectui/objectui/node_modules/.pnpm/...), and it pinsvite@5.4.21,@vitejs/plugin-react@4.7.0,vite-plugin-dts@3.9.1. The repo is now onvite@8.2.1/plugin-react@6.0.5/vite-plugin-dts@5.0.3, so the content is about seven months and three majors stale.It also embeds a snapshot of the config as it was then, which no longer matches
vite.config.ts: the live config aliases twelve@object-ui/*specifiers to sibling sources and passescompilerOptions/aliasesExcludeto the dts plugin; the frozen copy has a single@alias and a baredts({ insertTypesEntry, include }).Why it is inert
vite.config.{js,mjs,cjs,ts,mts,cts}; this basename isvite.config.ts.timestamp-..., which matches none of them.vite.config.tsis what is read.@object-ui/plugin-editor'sfilesis["dist", "README.md", "CHANGELOG.md", "LICENSE"], so it stays out of the tarball. (This is why it is a separate finding from @object-ui/fields 与 plugin-editor 的 build 程序把测试文件一起编译,73 个 *.test.d.ts 落进已发布的 dist/ #4006, whose subject is the published surface.)So the cost is a reader stumbling on a stale second copy of a config and having to work out which one is live — plus the ignore gap below, which is the part that can recur.
The reusable half:
.gitignorehas no rule for itVite writes these on every config load and normally removes them, but a crashed or killed process leaves one behind; nothing stops the next broad
git addfrom committing it again. A single root rule would close that:Adjacent but distinct from #3592 (
__dirnamein 28 vite/vitest configs) — that one is about the live configs' contents, this one is about a stale artifact sitting beside one, so it is filed separately rather than as a comment there.Suggested shape, if it is ever picked up
Delete the file and add the ignore rule; both are one-liners and belong together, since deleting without the rule leaves the recurrence path open. Worth confirming first that nothing references the path (a grep at the time of this filing finds no reference).
Generated by Claude Code