Peacock for Visual Studio Code Files

Features

• Added automatic migration that backs up existing workbench.colorCustomizations on first extension activation, preventing data loss when installing Peacock in workspaces with pre-existing color customizations. Users receive a notification with the option to view backed-up settings (#687)

Fixes

• Fixed a release-blocking vsce package failure: dependabot PR [#733] bumped @types/vscode to ^1.134.0 without a corresponding engines.vscode bump, and vsce refuses to package when the declared type definitions are newer than the minimum VS Code version the extension claims to support (@types/vscode ^1.134.0 greater than engines.vscode ^1.49.0). Reverted @types/vscode to 1.49.0 to match the existing engines.vscode floor rather than raising the minimum supported VS Code version as a side effect of an unrelated dependency bump — Peacock's code doesn't use any VS Code API newer than 1.49.0
• Fixed title bar text readability on dark color schemes in Cursor IDE. Peacock now gates the mid-gray title bar foreground workaround (#647) behind a background.isLight() check, using adaptive light foreground (#e7e7e7) for dark schemes to maintain WCAG AA contrast ratios while preserving the toolbar icon visibility fix on light backgrounds (#700)
• Fixed a tinycolor2 CJS/ESM interop bug: color-library.ts's import * as tinycolor from 'tinycolor2' compiles to a raw require() under the project's classic (non-esModuleInterop) TypeScript/webpack build, but under Vite/esbuild's stricter ESM semantics a namespace import can never be callable, so any color-manipulation call built with Vite (including the new Vitest unit lane) failed with TypeError: ... is not a function. Switched to import tinycolor = require('tinycolor2'), which compiles identically (a plain require()) under both toolchains (#670)
• Reconciled the title bar foreground fix (#700) with the extracted getTitleBarForegroundForApp helper (#670) — the helper now takes the background color and applies the same light/dark gating as the host fix, instead of unconditionally overriding the Cursor foreground
• Removed the one-time workbench.experimental.modernUI compatibility notice. The root cause was upstream in VS Code: modern UI mode forced the title bar, activity bar, and status bar to transparent backgrounds/borders with !important, overriding Peacock's (and any theme's) color customizations — reported as [microsoft/vscode#326126](https://github.com/microsoft/vscode/issues/326126) "Some color theme settings and color customizations are ignored in modern UI mode", fixed by [microsoft/vscode#329701](https://github.com/microsoft/vscode/issues/329701) "Restore theme colors in Modern UI shell" (merged August 2026). This is confirmed by multiple independent user reports on #652, so the warning was no longer accurate and was confusing users (#711). Added a regression test asserting applyColor() writes an identical workbench.colorCustomizations payload whether modernUI is enabled or disabled, so Peacock's own write path stays provably UI-mode-agnostic. The first version of that test actually caught a bug in itself, not in Peacock: it compared VS Code's live WorkspaceConfiguration object directly, which carries get/has/inspect/update methods as own properties, so assert.deepStrictEqual failed on function-reference identity even though every real color value matched. Fixed by comparing plain data via getColorCustomizationConfigFromWorkspace() instead.

Docs

• Added a README comparison showing Peacock working identically in VS Code's classic UI and the new Modern UI, as a visual companion to the Modern UI compatibility fix above.
• Clarified peacock.affectStatusBar and peacock.affectStatusBarDebugging settings in documentation with dedicated "Status Bar Customization" section, three common scenario examples, and improved setting descriptions to make feature discoverability easier. Closed [#704] as this feature was already supported (#704)
• Synced AGENTS.md's Tech Stack/Testing/CI sections, which still described the pre-#670 single-lane Mocha-only setup — added the Vitest unit lane, the test:unit/package:check scripts, and the current 5-step CI pipeline. Also added a documented Release Process section (version bump, changelog finalization, verification checklist) ahead of the 4.4.0 release.

Infrastructure

• Test modernization (#670): every test, even a one-line pure-function check, previously had to boot a real VS Code extension host, which slowed the feedback loop and discouraged small, focused tests. Added a fast Vitest unit lane alongside the existing Mocha host lane, so logic that doesn't touch the vscode API gets isolated, sub-2-second coverage instead. Before: one Mocha-only lane, everything host-bound. After: 192 host tests (integration-level, real VS Code) + 142 unit tests (fast, pure logic) = 334 tests total, both lanes included in npm run test:coverage. Along the way this also caught and fixed a real production bug (see Fixes) and reversed a coverage regression an earlier draft had introduced by deleting host assertions without unit replacements — the unit lane only replaces a host test where the underlying logic is genuinely pure, never as a blanket swap. Details below.
• Started test modernization by adding a dedicated Vitest unit lane (test:unit) and an explicit VS Code host lane (test:host), then moving pure suites (object-library, notification, foreground) to unit tests and extracting pure helper functions (title-bar-foreground.ts, favorite-color.ts, commands-helpers.ts) with unit coverage for the branches those helpers own (#670).
• An earlier draft of this migration deleted several host-suite assertions (notably around darken/lighten, affectedElements toggles, excludedSettings reset behavior, and sidebar color removal) without an equivalent replacement, which would have reduced actual coverage. Restored that coverage as host tests — the unit lane only replaces host tests where the underlying logic is genuinely pure and the unit test exercises the same branches, not as a blanket substitution. Net result: 142 fast unit tests added, and host suite coverage is at or above its pre-migration baseline (#670).
• Wired the Vitest unit lane into test:coverage, which previously only instrumented the host suite and silently excluded all 142 unit tests from the coverage report. Added @vitest/coverage-v8, pinned to the installed Vitest version, reporting to coverage/unit/ alongside the host suite's existing coverage/ output.
• Fixed two pre-existing host test bugs (from [#700]/#687, merged with CI red) that only surfaced once this branch ran the full merged suite: cursor-titlebar.test.ts's dark-scheme test passed the color wrapped in an array instead of as a plain string; two migration.test.ts tests tried to stub .update directly on the real (non-configurable) vscode.workspace.getConfiguration() object, which sinon 22 correctly rejects — both now follow the working pattern already used by the third test in that file (stub the getConfiguration() factory itself).
• Grouped Dependabot updates (.github/dependabot.yml): npm minor/patch bumps into one PR, npm major bumps kept separate for extra scrutiny, and all GitHub Actions bumps grouped together — cuts down on the 11-separate-PRs triage burden.
• Added an automated VSIX packaging check (npm run package:check, wired into CI): fails the build if dev-only files leak into the published package or the package exceeds a size threshold. Found and fixed real drift while adding it — .claude/skills/ai-ready/, .husky/, eslint.config.js, and tsconfig.eslint.json had all started shipping in the VSIX unnoticed (added .vscodeignore entries), inflating it from the ~243 KB baseline to 263 KB.
• Modernized linting (#724): the project had been pinned to eslint@6.8.0 and @typescript-eslint@2.34.0 (2020-era) with a legacy .eslintrc, which was the real reason TypeScript, @types/node, and Vitest couldn't be bumped — not a technical requirement, just years of unaddressed drift. Migrated to ESLint 10 with flat config (eslint.config.js, replacing .eslintrc), the unified typescript-eslint@8 package (replacing the separate @typescript-eslint/eslint-plugin/parser@2), and bumped TypeScript from 3.9.7 to 5.9.3 (the newest version typescript-eslint@8 supports). This unblocks the next steps in [#724] (@types/node, Vite/Vitest) as follow-up PRs. Fixed the handful of real issues the stricter modern rules caught: two test files' require-style imports (import x = require('y')) normalized to the codebase's dominant import * as x from 'y' convention, two {} parameter types tightened to Record<string, unknown>, three unused catch (err) bindings simplified to catch, and one untyped Promise in the Mocha test runner explicitly annotated Promise<void>. color-library.ts/title-bar-foreground.ts keep their intentional import tinycolor = require(...) (see [#670] above) via a documented eslint-disable-next-line.
• Bumped @types/node from 12.12.16 to 20.19.43 (#724) — matches the Node 20 runtime CI already builds/tests against, and is the minimum version modern vite/vitest require as a peer (>=20.19.0). This clears the second blocker in the toolchain chain (after [#725]'s ESLint/TypeScript bump); the last remaining step is a coordinated vite/vitest major bump.
• Bumped CI's Node runtime from 20 to 22 (ci.yml, copilot-setup-steps.yml, docs.yml) and @types/node from 20.19.43 to 22.20.1 to match, then bumped vitest/@vitest/coverage-v8 from 0.34.6 to 5.0.0 (vitest@5 requires @types/node ^22.0.0 || >=24.0.0 as a peer, which the previous Node 20 baseline couldn't satisfy). Renamed vitest.config.ts to vitest.config.mts and swapped __dirname for import.meta.dirname to clear Vitest 5's native-ESM-config warnings; no behavior change, all 142 unit tests still pass (#724).
• Bumped eslint 10.7.0 → 10.9.1 (patch), and @playwright/test, @types/vscode, webpack, webpack-cli to their latest compatible versions — routine dependency housekeeping cleared as part of the same modernization pass (#724).
• Toolchain modernization complete (#724): closing out the chain above. Current state: ESLint 10 (flat config), TypeScript 5.9.3, @types/node 22.20.1, vitest/@vitest/coverage-v8 5.0.0, CI on Node 22, and the Dependabot queue is fully clear — every PR blocked on this chain (11 in total) is now either merged in equivalent form or closed with an evidence comment. Two items are intentionally not pursued further: TypeScript 7 (no typescript-eslint release supports it yet — it hard-caps TS at <6.1.0) and @types/node 26 (superseded; 22.20.1 is the correct match for the Node 22 runtime CI actually uses). Two small follow-ups remain identified but deferred to their own dedicated PRs: a glob/istanbul-lib-* major-version bump for the coverage-instrumentation files, and a prettier 2 → 3 upgrade (will produce a large reformatting diff, so it deserves review on its own).
• Migrated the host-test runner from the deprecated vscode-test package (last meaningfully updated years ago) to its maintained successor @vscode/test-electron. vscode-test's hardcoded assumptions about the downloaded VS Code .app bundle's internal layout on macOS had rotted against recent VS Code releases, causing spawn .../Contents/MacOS/Electron ENOENT when running npm test/npm run test:host locally on macOS even though the download itself completed successfully. @vscode/test-electron exposes an identical runTests() API, so the fix is a drop-in dependency swap. As a side effect, this also clears 3 of 5 npm audit findings that were rooted in vscode-test's own transitive dependencies.