search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.05k stars 29.21k forks source link

Support development extension installations #25159

Closed Gama11 closed 1 year ago

Gama11 commented 7 years ago

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:

joaomoreno commented 7 years ago

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 commented 7 years ago

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:

Gama11 commented 5 years ago

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.

Gama11 commented 4 years ago

@joaomoreno There seems to be a new extensions-development label that would be a good fit for this issue. :)

jbriales commented 1 year ago

@joaomoreno There seems to be a new extensions-development label that would be a good fit for this issue. :)

Did this fly anyhow? :) I.e. do we have any official way today to flag "development" extensions in .vscode/extensions/ to NOT to be overriden by auto-updates?

vscodenpa commented 1 year ago

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!

alexrp commented 1 year ago

Please do reconsider this.

I'm currently writing a compiler and standard library for a programming language, as well as a VS Code extension - all in the same repo. Being able to just install the in-tree extension and reload the window during development would be a much cleaner experience than having to keep 2 windows around, one of which has to be perpetually stuck in run+debug mode, even when I'm not debugging the extension at all. It's just unnecessary ceremony and waste of system resources.

It's particularly annoying because I use the C# extension, which can be fairly heavy on larger workspaces. I either need to manually stop the C# extension in the parent window (which also renders that window truly "useless" as it can't work with either language), or I need to pass --disable-extension <C# extension id> to the child window and then switch back and forth between the windows depending on the language I'm writing.

Nolan-O commented 4 months ago

I'm rewriting a large extension and need to test both the development and release versions against how they interact with LSPs. I can't uninstall or replace the installed version with the development version because I'm doing a functional rewrite and need to keep track of regressions. The extension development host is insufficient as a test environment because all my LSPs fail to start in it, so I can't test any of that functionality to begin with.

I tried installing two versions manually and the result is that both are automatically uninstalled when vscode starts again...

Installing extensions manually has also proved difficult, requiring vscode to be running and I have to interact with the GUI for it to work. The command line option just does nothing with my .vsix file. So the best approach other than doing nothing is to test version A, uninstall version A, restart vscode to install version B, test version B, then repeat the process in reverse, per every feature I want to test.

So unless i'm missing some secret sauce, I believe it is a stretch to say the development host is sufficient for testing the functionality of all extensions, and in doing so it makes scenarios where you cannot simultaneously test your extension for behavior and regressions, unless you're willing to spend much of your day fiddling with extension installations.

I don't know why vscode can't show two extensions if I have two different local versions, but I hope it's not some sort of a structural design issue.

Talv commented 4 months ago

vscode can't show two extensions if I have two different local versions

Look into --extensions-dir cli argument. It sounds like it'd do what you want, basically it provides a way to maintain distinct environments for extensionHost per window/workspace. And in likelihood you'd want to have a separate --user-data-dir too.