Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: improve command line options for extensions #37620

Closed
aliwatters opened this issue Nov 3, 2017 · 9 comments
Closed

Suggestion: improve command line options for extensions #37620

aliwatters opened this issue Nov 3, 2017 · 9 comments
Assignees
Labels
extensions Issues concerning extensions feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code
Milestone

Comments

@aliwatters
Copy link

A few improvements to command line options for extensions to allow debugging and issue reporting to be easier;

  1. code --list-extensions - report versions also
  2. code --disable-extensions --enable-extension <extension-name -- allow a single extension to be run
  3. code --list-extensions - show enabled/disabled status

HTH

@vscodebot vscodebot bot added the extensions Issues concerning extensions label Nov 3, 2017
@eamodio
Copy link
Contributor

eamodio commented Nov 4, 2017

I would definitely LOVE #2 -- that way I could quickly run with all extensions disabled except for the extension I want to profile! And of course the disabled extensions wouldn't be persistent -- so on next start (without the command line) would have everything the way I would normally run

@sandy081 sandy081 added the feature-request Request for new features or functionality label Nov 6, 2017
@sandy081 sandy081 added this to the Backlog milestone Nov 6, 2017
@ramya-rao-a ramya-rao-a assigned ramya-rao-a and unassigned sandy081 Aug 9, 2018
@ramya-rao-a ramya-rao-a modified the milestones: Backlog, On Deck Aug 9, 2018
@shanalikhan
Copy link

I have opened similar issue via API ( #15466 )
As extension installing / uninstalling via API not supported yet ( #14444 ) and CLI is supported for now, so it would be great if you can support those things and complete the extension management via CLI

In Settings Sync , currently im using custom requests for download and install extension as API doesnt provide ways to perform functions, i'm looking forward to change to CLI based extension installation / uninstall.

@ramya-rao-a
Copy link
Contributor

fyi #1 is already possible. Use the --show-versions flag when using --list-extensions

@ramya-rao-a
Copy link
Contributor

@sandy081 AFAIK, the disabled status of an extension is stored in the local storage which is available in the renderer process. The cli process doesn't have access to this information. Is that right?

If so, it is not possible to show the disabled/enabled status of an extension when listing them via --list-extension option.

@sandy081
Copy link
Member

True. But there are plans to bring that to CLI.

@ramya-rao-a
Copy link
Contributor

Is there any existing issue tracking those plans?

@jsejcksn
Copy link

I like this idea, but does --enable-extension need to be combined with --disable-extensions? Or can it can be a separate argument?

code --disable-extensions
code --enable-extension ms-vsliveshare.vsliveshare

And can it accept multiple extension ids so that more than one can be enabled?

code --enable-extension ms-vsliveshare.vsliveshare ms-vsliveshare.vsliveshare-audio

@EthanZeigler
Copy link

EthanZeigler commented Feb 11, 2020

What I'd love to see is the ability to use the console to deactivate and activate extensions not only globally but per workspace. That way, I can write scripts to set up a workspace with the needed extensions without having to make an extension pack for them. I can't stress how useful that is for people who are frequently creating new workspaces.

Something like this:
code --enable-extension --workspace <workspace-file> ms-vsliveshare.vsliveshare ms-vsliveshare.vsliveshare-audio

Edit: I looked through the source changes that enabled per-workspace extensions in the first place and I truly cannot decipher what is going on. There seems to be little to no documentation on this part of the codebase. I had considered trying to implement a crude method of adding extension control to the project settings file, but it turns out that the per workspace extensions are saved in some sort of internal cache I cannot figure out at all.

@sandy081 sandy081 added the *out-of-scope Posted issue is not in scope of VS Code label Oct 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extensions Issues concerning extensions feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code
Projects
None yet
Development

No branches or pull requests

8 participants
@eamodio @jsejcksn @aliwatters @shanalikhan @EthanZeigler @sandy081 @ramya-rao-a and others