Repository navigation
chore(vscode): speed up extension launch builds - #14179
Conversation
Run prepare:sdk first, then compile the CLI binary in parallel with the extension typecheck, lint, and bundle. The CLI compile does not depend on those checks, and the SDK must still be generated before the CLI bundles its source. Key the cached Solid JSX transform by file content instead of path and mtime, and store it in the OS temp dir so every worktree shares one warm cache. Write cache entries through a temp file and rename so concurrent builds cannot read partial entries.
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (1 file)
Incremental scope: Previous Review Summaries (5 snapshots, latest commit 44a6145)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 44a6145)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (1 file)
Incremental scope: Fix these issues in Kilo Cloud Previous review (commit 9e0bfa8)Status: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Previous review (commit df9dc1e)Status: No Issues Found | Recommendation: Merge Files Reviewed (1 file)
Incremental scope: Previous review (commit b94d43b)Status: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Previous review (commit bdee7aa)Status: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (2 files)
The content-hash cache key (file name + source + toolchain versions) and the temp-file-plus-rename write are sound, and the Reviewed by deepseek-v4.1-flash · Input: 0 · Output: 0 · Cached: 0 Review guidance: REVIEW.md from base branch |
Only use the shared disk cache when the current user owns a directory that other users cannot write to. os.tmpdir() is world writable on Linux, so a predictable directory created by another local user must not be trusted. Tighten permissions on an existing directory and fall back to the in-memory cache when the directory is unusable. Reclaim temp files left behind by a build killed between writing and renaming.
Isolate failures to a single file so an entry that disappears between readdir and stat cannot abort the sweep, and reclaim superseded .js entries as well as orphaned temp files so the shared cache stays bounded.
Reject a symlinked or relocated cache path so the ownership check, the chmod, and the sweep cannot be redirected into another directory. Gate the sweep to at most once a day, since the directory is shared by every worktree and retains entries for 30 days. Record the content key for each source path while its size and mtime are unchanged, so an unchanged file costs one stat instead of a read and a hash. The index is per worktree and rebuilt from the files each build loads.
Drop index entries whose file no longer exists so renames and deletions do not accumulate, and correct the comment that claimed this already happened. Only trust a recorded key once the file is older than the coarsest filesystem mtime granularity, so a same-length edit inside one timestamp tick cannot reuse the previous transform.
mtime alone can be preserved across a write by cp -p, rsync -t, touch -r or a restored snapshot, which would reuse the previous transform for the production bundle. ctime changes on every write and cannot be set by those tools, so compare it too and read the file whenever it moved. Raise the settling threshold above the coarsest filesystem mtime granularity so a same-tick edit cannot be trusted.
What Problem This Solves
bun run extensionspent most of its cold build time on sequential steps that do not depend on each other, and the Solid JSX transform cache was keyed by absolute path and mtime and stored inside each worktree. Every fresh Agent Manager worktree therefore started cold and re-ran Babel over every JSX file on its first build.Why This Change Was Made
build:launchranprepare:cli-binary, thenprepare:sdk, thenbuild:check:production. The CLI compile is mostly single threaded (~117% CPU) and writes only topackages/opencode/dist,bin/, andnode_modules/.kilo-cli-version. The typecheck, lint, and bundle checks readsrc,webview-ui, anddist, then writedist. The two sets do not overlap, so they can run at the same time.prepare:sdkstays first because the CLI bundlespackages/sdk/js/src, which the SDK build regenerates.The transform cache key contained the file path and mtime, so it could not be shared between worktrees and missed on every new checkout. The transform output depends only on the file name (for the inline source map), the source text, and the toolchain, so the key is now a content hash that includes
@babel/core,babel-preset-solid,babel-plugin-jsx-dom-expressions,@babel/preset-typescript, and@babel/plugin-transform-typescript. Cache entries live in a per-user directory under the OS temp dir and are written through a temp file and rename, so concurrent builds in different worktrees cannot read partial entries.User Impact
Faster extension development only. The launched extension and all built artifacts are unchanged; the production bundles are byte-identical before and after the cache change.
Evidence
Measured on macOS arm64 with wall-clock time. Machine load varied (other agents were running), so the warm numbers are medians of repeated runs.
build:launchafterbun installbuild:launchesbuild --production, cold vs warm transform cacheVerification:
shasum -a 256 dist/*.jsbefore and after the cache change: identical.bun test tests/unit/launch.test.ts: 4 pass.bin/,opencode/dist, SDK cache, eslint cache,dist/, and transform cache: passed end to end.[Kilo New]errors in the extension host log.Known limitation: existing worktrees keep a now unused
node_modules/.cache/esbuild-soliddirectory. It is harmless and disappears on the nextnode_modulesreinstall.