Produce and Publish the set of vscode built in extensions

The "builtin extensions" - What are they?

The "builtins", "built-ins" or "vscode builtin extensions" are a set of extensions that whose code resides in the public vscode repository. Some contain no code as such and contribute the means to perform static rule-based syntax highlighting (through contributing a TextMate grammar) and sometimes also some code snippets, for a particular programming language. E.g. vscode.bat, vscode.javascript. A few built-in extensions contribute advanced language support for a given language, including a Language Server, a debug adapter, command/tasks contributions and more. e.g. vscode.typescript-language-features, vscode.markdown-language-features, vscode.html-language-features, 'vscode.json-language-features'. Finally, some built-ins contribute misc potentially useful features, like various themes, integration to a 3PP services like vscode.github* and more.

Every sub-folder of vscode/extensions/ is one built-in vscode extension (with a couple of exceptions like node_modules after a build:

https://github.com/microsoft/vscode/tree/main/extensions

They are built along and packaged as a group (not individual .vsix), in the Visual Studio Code product as well as in products based on Code OSS and derivatives such as VSCodium. The built-in extensions are distributed as a part of their IDE product and are not made available separately, e.g. on the Visual Studio Marketplace.

Using the built-ins in Theia-based applications

See also: Consuming Builtin and External VS Code Extensions

In Theia-based application, there is often a need for the features provided by various built-ins. To obtain some or all of the builtin extensions, the IDE author can include all built-in extensions by adding to the app's package.json, the URL of one of our builtins extension pack - open-vsx.org, produced and published alongside the builtin extensions. It's possible to exclude unwanted extensions, referenced by the pack, by adding them to the theiaPluginsExcludeIds list. It's also possible to curate the exact list of wanted built-ins and add them individually to the application's package.json and let the user install more later if needed. In theory they could decide to bundle no built-ins at all, if that fits their purpose.

From the example Theia application, in section "theiaPlugins":

theiaPlugins": {
    "vscode.markdown-language-features": "https://open-vsx.org/api/vscode/markdown-language-features/1.64.2/file/vscode.markdown-language-features-1.64.2.vsix",
    "eclipse-theia.builtin-extension-pack": "https://open-vsx.org/api/eclipse-theia/builtin-extension-pack/1.70.2/file/eclipse-theia.builtin-extension-pack-1.70.2.vsix",
    "EditorConfig.EditorConfig": "https://open-vsx.org/api/EditorConfig/EditorConfig/0.14.4/file/EditorConfig.EditorConfig-0.14.4.vsix",
    "dbaeumer.vscode-eslint": "https://open-vsx.org/api/dbaeumer/vscode-eslint/2.1.20/file/dbaeumer.vscode-eslint-2.1.20.vsix"
  },

How to exclude certain pack extensions:

"theiaPluginsExcludeIds": [
    "ms-vscode.js-debug-companion",
    "vscode.extension-editing",
    "vscode.git",
    "vscode.git-base",
    "vscode.github",
    "vscode.github-authentication",
    "vscode.ipynb",
    "vscode.microsoft-authentication",
    "ms-vscode.references-view"
  ]

Producing

Publishing to openvsx.org

3PP IP / Security

3PP License Check

Eclipse Theia is an Eclipse Foundation project, we follow the Foundation's IP process regarding 3PPs (runtime dependencies as well as "build and test" dependencies, obtained from the public npm registry). See the Eclipse Foundation Project Handbook IP section for more details. We use dash-licenses to obtain (mostly) automated approval for the 3PP dependencies used to build the built-in extensions. This is done manually ATM, documented in details here

3PP Vulnerability Audit

At the moment this is only informational. This check uncovers known vulnerabilities in 3PP dependencies, in specific versions of dependencies, used by the current set of builtins. There used to be a lot when we were a couple of years late in producing a set of older built-ins. The portrait has recently improved a lot, because we have made rapid progress in supporting newer vscode extensions API versions. This means the vscode built-in extensions we produced recently are based on more recent packages, that have accumulated less vulnerability reports. When we catch-up and stay on top of new APIs as they are released, the built-in extensions we build will have close to zero vulnerabilities, in the moment when we produce and publish them, just like their twins that are part of the most recently released version of Visual Studio Code product.

See here for how to run yarn audit, for the full set of built-in extensions.