Support development extension installations

[Gama11]

VSCode Version: 1.11.2

I have the vshaxe extension cloned into .vscode/extensions/vshaxe, which is the usual workflow for working on extensions as far as I can tell. I didn't have the most recent commit pulled yet, so the version in my local package.json was behind the officially relased one. This leads to VSCode actually asking me to update the extension (which doesn't make a lot of sense for an extension installed from source):

When you do this, VSCode installs the extension as it usually would, into a nadako.vshaxe-1.5.1 folder, which then actually overrides the development installation of the extension on the next restart. This alone wouldn't be a huge issue, but I had "extensions.autoUpdate": true in my settings, so this happened without me realizing it.

It seems that there's an assumption here somewhere that a development installation of an extension will always have a version that's >= the version of the latest release. However, there are a number of reasons why this might not be the case:

• As an extension developer, you might not have pulled the most recent commit(s) yet.
• As an extension developler, you might want to check out out older commits to git bisect something.
• As an extension user, you might want to install an extension from source to be able to roll back to an earlier version of it because the most recent version broke something (I don't think there's currently another way to install older versions of extensions? Related: Feature Request - Add GUI for installation of previous extension versions #25142).

[joaomoreno]

We don't have the concept of a development extension installation.

Is this really a desired scenario though? Isn't the fact that you can run the extension in a debug instance F5 sufficient?

[Gama11]

Ah, interesting. So I guess installing extension repos into .vscode/extensions is not the intended workflow, rather cloning them into some other location and then only tetsting them via the Extension Development Host?

Isn't the fact that you can run the extension in a debug instance F5 sufficient?

I don't think it is, at least not for my workflow. I basically only use the Extension Development Host when I want to debug the extension using breakpoints, otherwise I just rebuild + reload the window.

However, the main reason why I want the dev version of the Haxe extension to be available for all VSCode instances I open is that it makes it a lot easier to notice regressions / issues. That way, whenever I'm working on a Haxe project, I'm also testing the current dev build of the Haxe extension itself.

As I mentioned, there's use cases apart from extension development as well, for instance rolling back to an older versions of an extension (at least while there isn't an official way of doing so).

Also, there's cases where you need to have multiple dev extensions running / built from source, for instance if you're developing an extension API that can be consumed by other extensions.

---

It's not too uncommon for extensions to recommend this workflow (cloning into the .vscode/extensions dir). Here's a few of the more popular ones I could fine:

• Instant Markdown (100k installs)
• vscode-open-in-github (24k installs)
• vimStyle (17k installs)
• you can find more by googling for inurl:marketplace .vscode/extensions

[Gama11]

Hm, current Insider's Builds seem to modify the package.json of "development extension installations" by adding a __metadata field. This didn't happen in 1.30 or earlier.

Assuming this isn't meant to be committed / shipped with releases, this is kind of annoying.