So I have a great many extensions, and on any given project, I find myself using maybe a third of all of them (If I'm working on a Python project, I don't really need JavaScript related extensions now do I?). The problem is that right now VS Code loads and enables every single extension installed at the start of each new project. I find it a pain to then have to manually go and disable all the extensions I won't be needing for the project.
Is there a way to setup VS Code to only enable certain extensions when opening a new folder / workspace? I couldn't find anything in the docs on that subject and when looking at the extension section of the preferences I couldn't find such a functionality.
As of Feb 2023, it is now possible to create different Profiles in VS Code.
A Profile can include extensions, settings, keyboard shortcuts, UI state, tasks, and user snippets. You can customize VS Code for different development scenarios like data science, documentation writing, or for multiple programming languages like Python or Java. If you have different VS Code setups based on workflow such as "Work" or "Demo", you can also save those as different profiles. You can open multiple workspaces (folders) with different profiles applied simultaneously.
The following image demonstrates a folder opened with a Work profile that is customized for a work setup.
To my knowledge, the best you can do is use the Enable, Enable (Workspace) and Disable, Disable (Workspace) options.
Here is how ended up doing this:
Open a new workspace / folder.
Disable all extensions using Disable.
Enable all extension that you want to have enabled in every new project with Enable.
Enable extensions that you only want to use in this particular workspace / folder with Enable (Workspace)
From then on, when you open a new workspace, only the "default" extensions should be enabled. If ever you want to disable one of these "default" extensions in a particular workspace but still want it to be a "default" extension, make sure to use the Disable (Workspace) option.
Related
I want to apply a setting for a specific file, the only answers I've seen for this topic have been language-specific settings. How can I achieve this?
At this time, you cannot achieve this natively. According to their documentation they state:
VS Code provides two different scopes for settings:
User Settings - Settings that apply globally to any instance of VS Code you open.
Workspace Settings - Settings stored inside your workspace and only apply when the workspace is opened.
You would have to file a feature request on their github for support
Idea:
I wanted to clean up my vscode extensions, because I'm working with a lot of different languages/file types and having all these extensions installed and enabled at once is just too much.
Problem:
I disabled some extensions for a specific workspace, and wanted to copy these settings to another workspace, but vscode is not storing the information about enabled/disabled extensions in .vscode/settings.json.
Questions:
Is there any way to copy these settings from one workspace to another?
Is there a better way of dealing with lots of extensions?
Can you recommend tools/extensions for managing extensions per workspace or language(s)
I assume vscode is not loading all extensions at once, but rather when needed. But some extensions display icons on the left or bottom of the window and overcrowd the "Show All Commands" list/search.
VS Code stores this info in its internals instead of the .vscode folder, so you can't copy this info between workspaces. There is an open issue asking exactly what you want.
But, you have an alternative. Use the Profile Switcher extension.
Its description:
This extension allows you to define a number of settings profiles that you can easily switch between. The original idea for this extension came from my desire to have an easy way for me to switch my VS Code to a setup that was better optimised for presenting (changed themes, increase font size, etc).
And this is how it handles extensions:
A profile isn't just the settings you have enabled, but also the extensions that were installed. This allows you to create different profiles for different styles of development (e.g. a React profile and a Vue profile, loading their respective extensions only).
Hope this helps
There is a github issue for this problem: Feature Request: Enable/disable extensions from config file #40239.
I posted there a workaround using multiple vscode instances: link
Here is a copy-paste:
I use some kind of workaround to be able to use the extensions I want.
According to the vscode-cli your can specify the folders for extensions and user-data:
Options Description
--extensions-dir <dir> Set the root path for extensions.
--user-data-dir <dir> Specifies the directory that user data is kept in. Can be used to open multiple distinct instances of Code.
Basically, I create a specific folder for my specific tasks (one of front, one for back, ..) and set basic extensions to my default vscode.
To launch my custom config:
code --extensions-dir "$HOME/.vscode/profiles/my-super-profile/extensions" --user-data-dir "$HOME/.vscode/profiles/my-super-profile/data"
The problem are that:
It's not REALLY a project config file but a global preference file
I had to install manually the extensions. I believe there is a hackish way to do this
It use more size than necessary (multiple vscode data / duplicate extensions)
It doesn't solve in a clean way the team-sharing problem
I have a lot of projects to maintain; they require different plugins to operate. But, some plugins are heavy and make VSCode slow.
I want a plugin-set to be applied when I open one project and not to others.
In this way my VSCode will be light-weight.
You need to go to Extensions (CTRL+SHIFT+E) in the Activity Bar, click the cogwheel next to an extension and select Disable (Workspace). Apparently it's also possible to disable an extension globally, and make it activate only if it's explicitly enabled in {workspace}/.vscode/settings.json.
As #Artur said, you have to either have to disable or enable each extension by workspace. Not the most elegant of solutions.
Better solutions have been requested a few times, see workspace settings for extension lists and persisting extension load with a manifest file. The feature seems desired but no real indication of movement on the issue other than what Artur said.
I can get#recommended:workspace extensions to work correctly but I am unsure as to why I cannot get the general #recommended to show anything. Where am I supposed to put the extensions.json file?
My goal here is to have PowerShell install VSCode, copy over some JSON files for specific settings and then have the user shown the companies recommended extensions to install once they open up VSCode.
I know I can force them installed with code --install-extensions but I want the user to be able to pick and choose from the companies recommended list based on what kind of files they'll be working on. What I can't seem to figure out is how to get that list to show except within a workspace.
For example, we have a Chef team, an Azure team, Linux team, etc. each needing different extensions.
The #recommended option has no config. VS Code decides which extension to recommend based on the file types that exists in the folder/workspace that you opened (official release info).
So, in your scenario, I guess the best option is to use Workspace Recommendations (#recommended:workspace), using a different recommendation for each team/project.
I write code in several languages (Python, C, C++, and Java) using Eclipse. Is it possible to designate a directory on my machine (say /home/workspace/) as the "primary" workspace for any Eclipse session, but then to have subfolders, /home/workspace/python, /home/workspace/java, etc., in which I can create new Eclipse projects.
I don't want to have to navigate menus and select different workspaces for each session of Eclipse that I start up. I would rather just always have permission to manipulate any projects from a variety of folders at any time, but I can't find a clear answer about whether this can be done and how to do it.
As I understand your question; You want to have one workspace, but be able to code in several different languages without switching workspace but at the same time keep the projects separated?
First I would suggest you consider several workspaces, I find it convenient to keep settings and projects in separate workspaces. I rarely have to switch language that often.
But. I think what you want to do is to keep several working sets. You create one java working set, one C++ set and associate your different projects with a working set. Then you can minimize the java working set when you are running C++. For working sets you dont need any subfolders on the harddrive.
You might also want to look into Mylyn. Its a great tool for those who often are switching context. It saves the context (eclipse perspective, open files, etc) as associated with a task.
How about setting Eclipse to prompt for the workspace at launch? It wouldn't allow you to work in two languages at once, but should do the trick otherwise.
An Eclipse workspace can contain projects slated for different languages and those projects can live anywhere on your hard drive. There are at least two ways to do what you want. When creating a new project, uncheck the Use default location checkbox and browse to or specify the folder where you want your project to live. If a project already exists import the project into the workspace using the File->Import menu option and then select Existing Projects into workspace. In the next screen make sure the checkbox for Copy projects into workspace is not selected. This will leave the source files in the original folder.
In the Project explorer view, all the projects are going to look like they live at the root level. However you can group related projects into working sets. Then select just the working set you're interested in and all the others will disappear from view.
A warning is in order if you make use of eclipse variables in external tools (and possibly elsewhere). The syntax you use for paths needs to be adjusted. For example with projects outside the workspace this syntax ${workspace_loc:/MyProject/MyFile.txt} is no longer the same as this syntax ${workspace_loc}/MyProject/MyFile.txt