VS Code: Source Code Organization

[xwcoder]

VS Code: Source Code Organization

extensions/ 
src/vs
├── base
├── code
├── editor
├── platform
├── server
└── workbench

extensions: Built-in extensions

core: a layered and modular core (src/vs)

Layers

• The core is partitioned into the following layers:

  

  • base: Provides general utilities and user interface building blocks that can be used in any other layer.
  • platform: Defines service injection support and the base services for VS Code that are shared across layers such as workbench and code. Should not include editor or workbench specific services or code.
  • editor: The “Monaco” editor is available as a separate downloadable component.
  • workbench: Hosts the “Monaco” editor, notebooks and custom editors and provides the framework for panels like the Explorer, Status Bar, or Menu Bar, leveraging Electron to implement the VS Code desktop application and browser APIs to provide VS Code for the web.
  • code: The entry point to the desktop app that stitches everything together, this includes the Electron main file, shared process, and the CLI for example.
  • server: The entry point to our server app for remote development.

Target Environments

• Inside each layer the code is organized by the target runtime environment. This ensures that only the runtime specific AIPs are used.

  

  • common: Source code that only requires basic JavaScript APIs and run in all the other target environments
  • browser: Source code that requires Web APIs, eg. DOM
    • may use code from: common
  • node: Source code that requires Node.JS APIs
    • may use code from: common
  • electron-sandbox: Source code that requires the browser APIs like access to the DOM and a small subset of APIs to communicate with the Electron main process (preload.js)
    • may use code from: common, browser, electron-sandbox
  • electron-main: Source code that requires the Electron main-process APIs
    • may use code from: common, node
  • [⚠️ deprecated] electron-browser: Source code that requires the Electron renderer-process APIs. As mentioned before, VS Code is migrated to sandbox.
    • may use code from: common, browser, node

VS Code Editor source organization

• The vs/editor folder should not have any node or electron-* dependencies.
• vs/editor/common and vs/editor/browser - the code editor core (critical code without which an editor does not make sense).
• vs/editor/contrib - code editor contributions that ship in both VS Code and the standalone editor. They depend on browser by convention and an editor can be crafted without them which results in the feature brought in being removed.
• vs/editor/standalone - code that ships only with the standalone editor. Nothing else should depend on vs/editor/standalone
• vs/workbench/contrib/codeEditor - code editor contributions that ship in VS Code.

Source Code Organization

VS Code Workbench source organization

• The brief introduction

  • The VS Code workbench (vs/workbench) is composed of many things to provide a rich development experience, such as full text search, integrated git and debug.
  • The workbench does not have direct dependencies to all these contributions. Using an internal (as opposed to real extension API) mechanism to contribute these contributions to the workbench.

• Folders in a nutshell

  • vs/workbench/{common|browser|electron-sandbox}: workbench core that is as minimal as possible
  • vs/workbench/api: the provider of the vscode.d.ts API (both extension host and workbench implementations)
  • vs/workbench/services: workbench core services (should NOT include services that are only used in vs/workbench/contrib)
  • vs/workbench/contrib: workbench contributions (this is where most of your code should live)

• There are some rules around the vs/workbench/contrib folder

  • there cannot be any dependency from outside vs/workbench/contrib into vs/workbench/contrib
  • every contribution should have a single .contribution.ts file (e.g. vs/workbench/contrib/search/browser/search.contribution.ts) to be added to the main entry points for the product.
    • if you add a new service which is only used from one contrib and not other components or workbench core, it is recommended to register the service from the contrib entrypoint file
  • every contribution should expose its internal API from a single file (e.g. vs/workbench/contrib/search/common/search.ts)
  • a contribution is allowed to depend on the internal API of another contribution (e.g. the git contribution may depend on vs/workbench/contrib/search/common/search.ts)
  • a contribution should never reach into the internals of another contribution (internal is anything inside a contribution that is not in the single common API file)
  • think twice before letting a contribution depend on another contribution: is that really needed and does it make sense? Can the dependency be avoided by using the workbench extensibility story maybe?

VS Code for Desktop / VS Code for Web

• There are entry files that define all the dependencies depending on the environment:
  • src/vs/workbench/workbench.desktop.main.ts: for desktop only dependencies
  • src/vs/workbench/workbench.web.main.ts: for web only dependencies
  • src/vs/workbench/workbench.common.main.ts: for shared dependencies

Source Code Organization