src/contains the VS Code extension code (extension.tsentry), with core logic incore/(API handler, task runner), workflow helpers inmanagers/, tool adapters intools/, and sidebar/webview glue inui/.webview-ui/houses the React + Vite client; build outputs land inwebview-ui/dist/and are bundled into the extension.assets/stores icons for the activity bar; build artifacts go todist/viaesbuild.js; root configs (tsconfig.json,eslint.config.mjs,pnpm-workspace.yaml) apply to the extension workspace.
- Install dependencies with
pnpm install. pnpm run compiletype-checks, lints, and builds the extension intodist/;pnpm run packagedoes the same with production flags.pnpm run watchruns esbuild and TypeScript watch in parallel; usepnpm run watch:esbuildorwatch:tscwhen you only need one loop.pnpm run lintruns ESLint;pnpm run check-typesruns strict TS checks.pnpm testdrives the VS Code integration harness; regenerate test output withpnpm run compile-testsbefore running.
- TypeScript is strict (
tsconfig.json); keep source insrc/and never editdist/by hand. - ESLint enforces curly braces, strict equality, semicolons, and import names in camelCase/PascalCase. Use camelCase for vars/functions, PascalCase for classes/components, and SCREAMING_SNAKE_CASE for constants.
- Match the existing formatting (tabs present in TS files); avoid large reformat-only diffs unless agreed upon.
- Use Mocha-style tests (types provided) co-located as
*.test.tsnear the code under test (e.g.,src/core/task.test.ts). - Cover new behaviors and permission flows; include success and failure assertions, especially around
core/task.tsand API handlers. - Run
pnpm run compile-teststhenpnpm testbefore PRs to ensure the VS Code runner passes.
- Follow the conventional commits observed here (
feat:,fix:,chore:); keep messages imperative and scoped. - PRs should describe scope, link issues, list manual test steps, and attach UI screenshots/GIFs when touching
webview-ui. - Update docs and changelogs when behavior or settings change; note any new configuration keys under
contributes.configuration.
- Never hardcode API keys or endpoints; use the
codeSidecar.api.*settings and keep secrets out of git. - Review permission defaults (
codeSidecar.permissions.*) before shipping and avoid committing generated artifacts (dist/,node_modules/).
- Keep the code concise and clean. Avoid over-defensive programming; do not add excessive safety checks or unnecessary try-catch blocks.
- No backward compatibility - Break old formats freely
- When there is duplicated logic or similar code blocks, consider extracting them into a shared module or separate file.
- If the content of a file is too large or contains multiple responsibilities, the code MUST be split into multiple smaller files, each with a clear, single responsibility and an explicitly stated filename.
- If a single source file exceeds 500 lines, consider refactoring it into smaller, well-defined modules to improve readability, maintainability, and testability.
- Prefer leveraging well-maintained libraries or external packages if they can simplify the implementation and improve code maintainability.
- The overall visual style should be clean, minimal, and elegant.
- Prioritize clarity and simplicity over decoration.
- Avoid borders or boxed layouts; use whitespace and alignment to define structure instead.
- Layouts should feel lightweight and unobtrusive, with a focus on content readability.
- Do not use a gradient background.
- Do not use any Python commands.