VSCode@Insiders Support for Extensions

[DeanFoley]

👋 more of a feature request than an issue!

Being able to bulk install VSCode extensions with Brew is absolutely superb; you can even use something like yadm to have machine/context-specific lists of extensions, absolutely great stuff.

I just bootstrapped a new MacOS installation using Brew to install my VSCode plugins and I'm deciding to use the Insiders build on this machine rather than the stable build. I think it would be cool if, similar to how Brewfiles can be used to bulk-install VSCode extensions, you could also do the same for VSCode@Insiders installations!

Obviously quite a few ways this could work, such as a vscode-insiders prefix in Brewfiles, but wanted to float the idea before talking too much about potential implementations. Is this something that the project maintainers would be interested in implementing, or is it a bit too niche of a use-case?

Cheers!

[jacobbednarz]

we spoke about other distributions in the initial implementation thread and i don't think we're opposed to it but would be looking for someone who uses this particular distributions to drive the implementation.

personally, i'd +1 this if the build is within the existing vscode stanza. example: vscode "foo", build: "code-insiders" where build is the binary name. i'm not tied to the naming here so open to suggestions if someone else has a preference to use something like binary_name to make it more flexible again.

[DeanFoley]

personally, i'd +1 this if the build is within the existing vscode stanza. example: vscode "foo", build: "code-insiders" where build is the binary name.

That actually is exactly how one can do it!

code-insiders --install-extension "golang.go"

I was hoping to jury-rig some solution that would work for me locally but unfortunately I don't know enough about the under-the-hood specifics of Brew to make it work for me.

[jacobbednarz]

you should be able to lean on comments from the initial implementation at https://github.com/Homebrew/homebrew-bundle/pull/1208/files#diff-363c350ab43f9059092b91432596c9ffb0628baf849b8f4dfedbd8dae0e7299aR29 and https://github.com/Homebrew/homebrew-bundle/pull/1208/files#diff-f9ae0ee608c877b4ccb13c808f9112b4fe03379a7deea9f1919b7b6d558a7bd4R33. from there, you will need to pass through a flag to swap out the binary.

[MikeMcQuaid]

I think we should just fall back to a code-insiders binary if code is not found.

Will review a PR for this but closing for now.

[jacobbednarz]

that could definitely work if the operator only has a single binary installed. i don't use vscode anymore however, when i did, i had stable and insider builds installed alongside one another which wouldn't work here but the option of assuming code and allowing it to be overridden on a per install level would allow us to cater for both.

[MikeMcQuaid]

I'd rather we supported the simplest option first and then considered extending later if needed. I'd also rather any complexity be pushed into e.g. environment variables rather than Brewfiles.