Document how to use OSS build as a daily driver

[ghost]

Need to document how to get an OSS build into working condition as a daily driver.

Having this process documented in a central location would also be useful for package maintainers. (For example, if Ubuntu were to decide to start shipping vscode.)

Compared to the 0.10.8 (January) release of vscode, the oss build also includes vscode-api-tests, but it's removed in the release version, which makes sense.

The release version also includes jrieken.vscode-omnisharp, but the oss build doesn't. (Not really sure why. Probably an oversight?).

Aside from that, the only other difference I can find with the extensions is that the node-debug and mono-debug "extensions" in the oss build are just stub packages (node-debug-placeholder and mono-debug-placeholder).

As noted in issue #60, comment 6, the release ships with a different product.json. Some of the differences are cosmetic, others fill in service endpoints. Here are the most notable differences:

• The extensionsGallery property is set in the release build. Notable because it controls whether the "Install Extensions" item shows up in the command palette, and downstream packagers should set this to something appropriate if they want to enable extension downloads from within the product.
• The dataFolderName is changed. Notable because it controls where (some of) the user configuration and extensions are stored. If the VSCODE_DEV environment variable is set, it will use the directory name obtained by appending "-dev" to the dataFolderName value. (The vscode launch scripts for the oss build set VSCODE_DEV by default.)
• crash reporting and telemetry are enabled in the release build.

This isn't an exhaustive listing, but it's not meant to be. However, some document that includes this information needs to exist, and going ahead and mentioning it in this comment is a starting point.

[ghost]

Note that even following these steps, I'm still unable to get extensionHost debugging working, because pressing F5 launches the generic electron window instead of a child vscode instance:

1. Run git checkout 0.10.8
2. Delete the stub debuggers: rm -rf ./extensions/node-debug ./extensions/mono-debug
3. Download the actual debuggers with git clone https://github.com/microsoft/vscode-node-debug ./extensions/node-debug and git clone https://github.com/microsoft/vscode-mono-debug ./extensions/mono-debug
4. Change to each debugger directory and build them with npm install && gulp
5. Change back to the source root and run ./scripts/npm.sh install --arch=x64
6. Build product with gulp compile
7. Launch the build with ./scripts/code.sh
8. Open the source for amVim
9. Try to debug it by pressing F5

This is probably(?) from the difference in the way the app gets invoked. In the release, it's running the Code binary, but code.sh runs the build launching electron directly.

Screenshot showing generic electron window instead of a child vscode instance

[ghost]

Re #2863, package maintainers will probably want to change over to using locally generated sourcemaps instead of downloading them at build time.

[Tyriar]

@weinand any comment on why the debuggers don't work in oss?

[weinand]

@Tyriar the 'debuggers' just work fine in oss for 'normal' programs. This is not a debugger issue.

@ghost The issue with the use case from above is that electron needs to be launched in a way that it behaves like VS Code and not like a generic Electron app. For this it is necessary to pass the VS Code workspace path as a first argument to the runtime. Here is a modified launch config for that case:

Additional remarks:

• VS Code 1.0 has only one builtin debugger: node-debug. Mono-debug is a regular extension that exists on the Marketplace for historical reasons. For debugging of C# programs please use the C# extension.
• It is not necessary to remove the fake node-debug from the VS Code workspace. You can just install the node-debug extension from a recent VS Code drop into your extension folder: ~/.vscode-oss-dev/extensions or git clone the vscode-node-debug project into that location and build it there. Those extension will override VS Code's internal extensions.

@bpasero would it be possible to detect the use case from above and automatically pass the VS Code workspace path as the first argument? This would simplify the setup for extension developers who wants to selfhost on VS Code because they would not have to tweak their launch configs.

[Tyriar]

Closing this off, the requesters are all 👻