Visual Studio Code
Visual Studio Code combines an editor with language tooling, debugging, extensions, and remote development. For a team, begin with a reproducible workspace that explains how to build, test, and debug the project. Personal editor preferences can remain personal; shared settings should support a task the repository actually needs.
The goal is a teammate completing the same workflow from a fresh checkout. An editor configuration is useful evidence only when its runtime, extensions, paths, and permissions are understood.
TL;DR
- Separate user, workspace, language-specific, and remote settings.
- Commit only project-relevant configuration and avoid secrets or machine-specific paths.
- Use explicit debugger entry points and test them with the required runtime.
- Review extension publishers, execution behavior, and trust requirements.
- Verify the remote environment as a separate toolchain, not a mirror of local settings.
Quick Example
Create a new disposable folder with the following demo.code-workspace file and example.cjs beside it. The workspace uses built-in JavaScript/Node debugging and changes no global settings. It is a proposed fixture; no VS Code installation or user preferences were changed here.
Open the workspace in an authorized local VS Code session, review its contents, set a breakpoint on the assertion, and select the named debug configuration. Inspect result, step, and continue. Direct Node execution should print { result: 14 }; that checks the program, not debugger integration.
Core Concepts
Settings have scope and precedence
Workspace settings apply to the project and can be stored with it; user settings apply more broadly. Language-specific and remote settings add further scopes. The settings reference explains their precedence. When formatting differs between teammates, inspect the effective scope and selected formatter rather than repeatedly changing the same visible value.
Language features have a runtime path
Syntax highlighting, type checking, formatting, and debugging can come from different components. Record the required language server, runtime, compiler, and project configuration. A file opening without errors does not prove that the terminal build or deployed artifact uses the same toolchain.
Extensions and workspaces can execute code
Tasks, debuggers, language tools, and extensions may run binaries or project scripts. The Workspace Trust guide describes Restricted Mode and its limits. Review an unfamiliar repository and extension source before granting the capabilities needed to execute its workflow. Trust is a decision about code, not a visual theme setting.
Make One Workflow Reproducible
The debugging guide describes reusable launch configurations and breakpoint inspection. Include the actual entry point and working directory when a project needs them. Do not put credentials in committed launch arguments or environment values; use the approved local secret mechanism.
Remote SSH opens a remote workspace with tooling that may run remotely. Test where extensions execute, which filesystem the debugger sees, and whether the remote runtime matches CI. A local Node check cannot establish remote permissions, port forwarding, or debugger behavior.
Keep essential build and test commands usable outside the editor as well. This makes CI and another teammate's environment easier to compare, and it prevents a hidden editor task from becoming the only documented way to build the project.
Best Practices
Share only intentional settings
Choose settings that support project conventions, explain unusual choices, and avoid absolute machine paths. Test a clean checkout so an uncommitted extension or user setting does not become an invisible prerequisite.
Keep extension recommendations reviewable
Document why an extension is needed and where it runs. Recommendations do not guarantee an installation or validate a publisher. Reassess when an extension adds new execution or data-access behavior relevant to the workflow.
Verify the failure path
Introduce a controlled assertion failure, inspect the diagnostic or debugger stop, then restore the fixture. A configuration that runs only the happy path may point at the wrong file or hide an error exit.
Common Mistakes
Bad: Commit a teammate’s personal runtime path.
Correct: Use the intended portable configuration and document runtime installation separately.
Bad: Disable trust protections to make an unfamiliar repository run.
Correct: Review the code and required capabilities before executing the workflow.
Bad: Assume local extension behavior matches a remote session.
Correct: Verify runtime, extension location, paths, and permissions in the actual remote context.
FAQ
Must every teammate use identical preferences?
Share the settings needed for project behavior and conventions. Unrelated personal preferences need not be repository policy.
Does valid JSON prove the debugger works?
No. It establishes structure; the runtime and debug adapter must execute the intended entry point and stop at a meaningful breakpoint.
Is Restricted Mode a complete malicious-code sandbox?
It limits several automatic execution paths, but the official guide describes limits, especially for extensions. Keep code and publisher review part of the decision.
What remains unverified here?
VS Code UI, breakpoints, language-server/extension behavior, remote SSH, and a complete team environment were not exercised.
Related Topics
- IDEs & Editors — Choose tools around the actual workflow.
- Debugging — Inspect state and failure paths.
- Git Fundamentals — Share reviewed project configuration.