mirror of
https://github.com/microsoft/vscode.git
synced 2026-06-29 19:06:00 +01:00
Sandeep Somavarapu
27725b9a63
* sessions: resolve ${workspaceFolder} in agent-host tasks via IConfigurationResolverService
Agent-host worktree sessions build their task command line through
AgentHostSessionTaskRunner/resolveTaskCommand, which bypassed variable
resolution and sent ${workspaceFolder} to the terminal verbatim (causing
EROFS errors writing to a literal "${workspaceFolder}" path).
Expand variables using the workbench IConfigurationResolverService (already
registered in the Agents window), passing the session's worktree folder so
${workspaceFolder} resolves to the worktree rather than the Agents window's
own workspace. The resolver API is async, so the resolveTaskCommand pipeline
is now async; the hook is attached only when a cwd is known so variables are
left untouched otherwise.
Also adds the Agents-window worktree dev tasks (Install & Watch Client,
Run Client, Install & Watch) to .vscode/tasks.json, and tightens the
over-commenting guidance in the coding guidelines and sessions skill.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* sessions: address CCR feedback on agent-host variable resolution
- Resolve ${workspaceFolder} for remote hosts using the POSIX URI path
instead of IConfigurationResolverService.resolveAsync (whose fsPath uses
renderer-OS separators, wrong for a differently-OS'd remote host).
- Wrap the local resolveAsync call in try/catch so an unresolvable variable
(e.g. ${command:}/${input:}) leaves the string unchanged rather than
failing task dispatch.
- Fix the _getCwd comment to reference the real scheme (vscode-agent-host).
- Add a remote-host test asserting POSIX-path expansion and that the
renderer resolver is not consulted.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* sessions: make agent-host task runner test platform-independent
The expansion test asserted against the resolver substituting URI.fsPath,
which on Windows yields backslash separators. Backslash is in
POSIX_NEEDS_QUOTING, so the expanded arg was strong-quoted on Windows and
the unquoted assertion failed. Substitute the POSIX URI path instead so the
test is deterministic across platforms.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
70 lines
4.1 KiB
Markdown
70 lines
4.1 KiB
Markdown
---
|
||
description: VS Code coding guidelines — naming, style, types, strings, and code quality rules. Reference when writing or reviewing code.
|
||
applyTo: src/vs/**
|
||
---
|
||
|
||
# Coding Guidelines
|
||
|
||
Canonical reference: https://github.com/microsoft/vscode/wiki/Coding-Guidelines
|
||
|
||
Also see the [Source Code Organization](https://github.com/microsoft/vscode/wiki/Source-Code-Organization) wiki page.
|
||
|
||
## Indentation
|
||
|
||
Use tabs, not spaces.
|
||
|
||
## Naming
|
||
|
||
- PascalCase for types and enum values
|
||
- camelCase for functions, methods, properties, and local variables
|
||
- Use whole words when possible
|
||
|
||
## Types
|
||
|
||
- Do not export types or functions unless shared across multiple components
|
||
- Do not introduce new types or values to the global namespace
|
||
|
||
## Comments
|
||
|
||
- Use JSDoc style comments for functions, interfaces, enums, and classes
|
||
- Do not write large comments in the middle of a method or comments that explain a single line. If a line or block needs a paragraph of explanation to be understood, treat that as a signal that the code itself is unclear: extract a well-named function, introduce an explanatory variable, or simplify the logic instead. Keep any remaining inline comment to a brief note.
|
||
- **Default to NO comment.** Add one only when the code cannot be made self-explanatory by naming. Code that is obvious from its identifiers must not be commented.
|
||
- **Hard limits** (treat as rules, not suggestions):
|
||
- JSDoc on a function/interface/property: at most 1–2 short sentences. Do not enumerate every branch/feature, restate the signature, list what it does NOT do, or explain parameters that are obvious from their names/types.
|
||
- Inline comment inside a method body: at most 1 line, and only for a genuine workaround/hack, a non-obvious ordering constraint, or a surprising side effect. Never narrate the next statement (e.g. `// Expand the variable`, `// loop over args`).
|
||
- Before writing any comment longer than one line, stop and either delete it or shorten it to a single line. A multi-line block comment inside a method body is almost always wrong.
|
||
|
||
## Strings
|
||
|
||
- `"double quotes"` for user-visible strings that need localization
|
||
- `'single quotes'` for everything else
|
||
- All user-visible strings must be externalized via `nls.localize()` — no string concatenation, use `{0}` placeholders
|
||
|
||
## UI Labels
|
||
|
||
- Title case for command labels, buttons, and menu items (each major word capitalized)
|
||
- Don't capitalize prepositions of four or fewer letters unless first or last word
|
||
- Sentence case for view titles/headings (only first word capitalized), no trailing period
|
||
|
||
## Style
|
||
|
||
- Arrow functions over anonymous function expressions
|
||
- Only parenthesize arrow parameters when necessary: `x => x + x` not `(x) => x + x`
|
||
- Always surround loop and conditional bodies with curly braces
|
||
- Open curly braces on the same line
|
||
- No surrounding whitespace in parenthesized constructs
|
||
- Prefer `export function x(…) {…}` over `export const x = (…) => {…}` at top-level scope (better stack traces)
|
||
|
||
## Code Quality
|
||
|
||
- Include Microsoft copyright header in all files
|
||
- Prefer `async`/`await` over `Promise.then()`
|
||
- Localize all user-facing messages
|
||
- Prefer named regex capture groups over numbered ones
|
||
- Do not use `any` or `unknown` unless absolutely necessary
|
||
- Register disposables immediately after creation — use `DisposableStore`, `MutableDisposable`, or `this._register()`
|
||
- Declare service dependencies in constructors via DI — never access services through `IInstantiationService` elsewhere. In particular, do **not** lazily resolve a service with `this.instantiationService.invokeFunction(accessor => accessor.get(ISomeService))`; add `@ISomeService` as a constructor parameter instead. If a constructor cycle prevents direct injection, break the cycle (e.g. pass the dependency into an `init()`/wiring method from the orchestrator, or relocate the call) rather than reaching through `invokeFunction`/`accessor.get`.
|
||
- Use `IEditorService` to open editors, not `IEditorGroupsService.activeGroup.openEditor`
|
||
- Avoid `bind()`/`call()`/`apply()` solely for `this` — prefer arrow functions
|
||
- Avoid events for control flow between components — prefer direct method calls
|