The recent shift to bundle the GitHub Copilot Chat directly into the VS Code core (extensions/copilot) rather than distributing them via the microsoft/vscode-copilot-chat repository has changed some things.
Previously, daily driving a bleeding-edge commit meant building the .vsix and installing it just like a regular extension. Because the extension is now built-in, installing a locally built .vsix does not cleanly shadow the bundled built-in version. Now, overriding the built-in extension involves one of the following: replacing the system-level folders, using artificial version spoofing, or be forced to use --extensionDevelopmentPath.
The compile-copilot-extension-build task introduced in #309079 enables non-CI local builds to compile the built-in copilot extension from source. However, the resulting .build/extensions/copilot/node_modules in the final build output contains every production dependency (e.g., isbinaryfile, minimatch, etc.) from extensions/copilot/package.json (hundreds of packages), even though these are fully bundled into dist/extension.js by esbuild and are not needed at runtime. It's bloated for the purpose of daily driving a bleeding-edge the latest Copilot from source.
The extension that ships in CI builds only contains:
@vscode/copilot-typescript-server-plugin (package.json + dist/*.js)@github/copilot (package.json + sdk/ subtree only with the native Copilot dependencies like node-pty and ripgrep)
Reproduction
npm run gulp compile-copilot-extension-build
find .build/extensions/copilot/node_modules -maxdepth 2 -type d | head -30
You'll see hundreds of dependency directories. Compare with a released VS Code Insiders, for example in Linux:
ls /usr/share/code-insiders/resources/app/extensions/copilot/node_modules/
# Only @github/ and @vscode/
Feature Request
- Add a gulp task for building a concisely packaged Copilot Extension from source with correctly filtered
node_modules, producing output equivalent to what CI ships from the pre-built VSIX. This also materializes native dependency shims (node-pty, ripgrep) into the output.
cc @joaomoreno
The recent shift to bundle the GitHub Copilot Chat directly into the VS Code core (
extensions/copilot) rather than distributing them via themicrosoft/vscode-copilot-chatrepository has changed some things.Previously, daily driving a bleeding-edge commit meant building the
.vsixand installing it just like a regular extension. Because the extension is now built-in, installing a locally built.vsixdoes not cleanly shadow the bundled built-in version. Now, overriding the built-in extension involves one of the following: replacing the system-level folders, using artificial version spoofing, or be forced to use--extensionDevelopmentPath.The
compile-copilot-extension-buildtask introduced in #309079 enables non-CI local builds to compile the built-in copilot extension from source. However, the resulting.build/extensions/copilot/node_modulesin the final build output contains every production dependency (e.g.,isbinaryfile,minimatch, etc.) fromextensions/copilot/package.json(hundreds of packages), even though these are fully bundled intodist/extension.jsby esbuild and are not needed at runtime. It's bloated for the purpose of daily driving a bleeding-edge the latest Copilot from source.The extension that ships in CI builds only contains:
@vscode/copilot-typescript-server-plugin(package.json + dist/*.js)@github/copilot(package.json + sdk/ subtree only with the native Copilot dependencies likenode-ptyandripgrep)Reproduction
npm run gulp compile-copilot-extension-build find .build/extensions/copilot/node_modules -maxdepth 2 -type d | head -30You'll see hundreds of dependency directories. Compare with a released VS Code Insiders, for example in Linux:
ls /usr/share/code-insiders/resources/app/extensions/copilot/node_modules/ # Only @github/ and @vscode/Feature Request
node_modules, producing output equivalent to what CI ships from the pre-built VSIX. This also materializes native dependency shims (node-pty,ripgrep) into the output.cc @joaomoreno