Add Project Manager extension to VS Code

[1st]

I think that Projects ideology should be in a heart of the VS Code. The main reason for it it that we can have a dedicated folder for each project where we can save project settings (including workspace settings), cache files (for example for file tree to make Go To File super fast and save cache between VS Code reloads), to save cache of external plugins (like such as Python, that saves and uses cache for Go To Symbol In workspace).

Please discuss this decision again in your core team. Because I see that it should be implemented, and all what you need is to take the already existing extension and inject it into the native VS Code build.

Thank you for improvements.
Anton

[ramya-rao-a]

@anton #396 is tracking this feature, please add your thoughts there

We also have on-going work for the multi folder workspace in the current milestone (See #28387), so you will see some progress soon :)

[1st]

Sorry, but how is it related with my task? It's totally different request!

[1st]

@ramya-rao-a will be good to reopen this ticket. Or, maybe, you pointed me to a wrong ticket that you mentioned above?

[ramya-rao-a]

@1st, Ah sorry, I somehow missed the "extension" part of your issue description.

cc @Tyriar and @bpasero for more on multi root workspace and how that can help and how the Project Manager extension fits (or not) into all this.

[Tyriar]

Hi @1st, we do not want to ship a "real" project manager within VS Code right for a few reasons:

• There are multiple approaches to project management (example 1, example 2) and extensions cover these cases well right now.
• When we pull stuff into the core of VS Code it becomes less agile due to the more restrictive monthly release cycle.
• Someone on the small team would need to become an "owner" of the feature, taking effort away from other parts of the project that need attention.

As @ramya-rao-a called out, we're currently in the process of adding support for multiple folders (#396) which will impact the "project" capabilities of both VS Code out of the box and project management extensions.

[1st]

Hello @Tyriar.

In the #396 I found nothing interesting about support of projects. It's about opening two or more folders from different locations.

I don't know how do you work at Microsoft and which ideologies do you use, but please read my thoughts about this topic. I was working for a long time in software development as a web developer, starting from startups and ending Google. I found it's a "normal" or "standard" thing where you operate things as a PROJECT.

What is a PROJECT? It's a folder or multiple folders from different locations which we need to build this project. It can be a main source code, code of third party libraries, some modules that live in the external repositories. All these folders can live in different locations on a disc (not hierarchically). To allow your PROJECT operates, you need to know which folders you need to show in the navigation sidebar. Also you need to store settings for this project. Also you need to store cache files to speed-up "go to file", search and other things (let's say it's a hashmap to speedup search by key). And these cache files should live between our editor relaunches and be recalculated in background to allow start coding in a second after launch the editor. Where do you store these all files, that I mentioned above?

I know that you have a WORKSPACE settings. You know, it's strange to see that you try to save some meta files inside my source code folder. Why? Because in case of cache files and mounted sshfs file system - I have a huge lag every time when cache updates. I don't like it. It looks like you try to go back on 10 years and use SVN ideology in your modern Code editor. Please change your vision.

I propose to use for this purpose PROJECTS. But if you like WORKSPACE name - I agree on it as well. But thing should work properly. On Mac, I expect that I will have all project meta data located in a SINGLE PLACE - in the ~/.vscode/ foldet. Project name is customizable and saves in the settings file, the same file that you use to store settings for a workspace. In result, I will have next folders structure:

~/.vscode
../settings.js - a global settings for all projects
../project1 - a folder for each project to store meta data and data from plugins
..../settings.js - a settings for the project. Here we have the same data that we currently store for a workspace, plus project name and list of folders that we need to show in a files sidebar
..../cache - (folder) contains a cache from diferent plugins. Some plugins store cache files!
../project2
../..

Did you discuss such idea in your team? If not - please do it. If you need to have me on call - let's schedule a meeting and I will help you to make decision.

Best,
Anton

[Tyriar]

What is a PROJECT? It's a folder or multiple folders from different locations which we need to build this project. It can be a main source code, code of third party libraries, some modules that live in the external repositories. All these folders can live in different locations on a disc (not hierarchically).

#396 is adding support for this.

Also you need to store settings for this project.

For multiple folder settings there is an open discussion on #396. Settings can be stored in user data for user-specific settings (we may allow path-based user settings in the future) and workspace settings.

Also you need to store cache files to speed-up "go to file", search and other things (let's say it's a hashmap to speedup search by key).

Extensions are free to store this where they feel is best: in ram only, in user data (we expose an API to allow storing in a key-value store there), somewhere else (the path could be defined by a setting).

Where do you store these all files, that I mentioned above?

User data is the main place you're talking about, this is located at $HOME/Library/Application Support/Code on macOS.

---

Workspace settings are completely optional, I don't use them for my personal projects and you don't have to either. If something is saving settings in .vscode/settings.json you should identify the extension and report an issue.

If you want settings attached to folder(s) or to be able to assign a name to folder(s) then you should read some of the later summary comments in #396 and bring it up there. That is the issue you're looking for.

[1st]

Okey. It looks like not a "freedom for plugins", but a bad style that will end up with uncontrolled settings and cache files stored here and there, and also there. It's not serious solution you are using right now, as I see it.

I don't know why you selected this ideology but it will be harder for you to change your decision in future when you will release the breaking changes, when will add support for a dedicated place to store all META data.

For instance, now in the "Python" extension I see that cache file "ctags" stored into the .vscode subfolder inside my opened folder. I DONT LIKE THIS! As I mentioned above, I use a mounted sshfs that works pretty slow and each change to ctags file adds extra lag for me. Why user of VS Code should see in the code internals to find that "oh, this plugin writes data to my project's folder", instead of use editor without understanding of it's internal implementation?

You can't prevent plugins from writing to my opened folder because you don't have place where to store the cache data. You can't identify the workspace/project when I close VS Code and then reopen the window. How can you find cache files that was created in my previous session? It's no way to match an opened folder to a cache data. If you don't use cache, how can you optimize performance in future for the editor and underlying plugin in which used some cache between sessions? It's why you create a local subfolder .vscode in opened folder where you save workspace settings, and plugins save their cache files. But it's an SVN way. I prefere to store all data in one place. I don't like to see any new files created inside my source code folders. I explained above that in my particular case it ends up in an additional lag. I think that you can find other examples of why it's not good idea to store local settings and data spreaded around filesystem, instead of having them all in one place.

One more example. I wish to sync my VS Code settings between two computers. I upload one global .vscode folder to Dropbox, and use it on both computers. I don't wish to commit .vscode subfolders to git for each source code folder that I open. It's real use case. How can you solve it with your current implementation of spreaded configs?

You told also that you don't use a workspace settings. I use it. I have different settings in different projects. In one I have tab space set to 4, in other - on 2. In some I have one settings for plugin, in another - I use different settings. Workspace settings is useful, even if you don't use it personally.

Believe that you will find my comments useful and it will help your project to become better.

Best,
Anton

[Tyriar]

For instance, now in the "Python" extension I see that cache file "ctags" stored into the .vscode subfolder inside my opened folder.

Extensions can do whatever they want, we do not lock them down in where they store data, just provide some convenience APIs they can use. This would annoy me as well if I used Python, you should file an issue to the Python extension https://github.com/DonJayamanne/pythonVSCode

Why user of VS Code should see in the code internals to find that "oh, this plugin writes data to my project's folder", instead of use editor without understanding of it's internal implementation?

Remember VS Code is a developer tool, attempting to lock down file access for extensions would significantly limit their capabilities.

You can't prevent plugins from writing to my opened folder because you don't have place where to store the cache data.

We do provide an API to store that data against a workspace in the user data directory mentioned earlier https://code.visualstudio.com/docs/extensionAPI/vscode-api#_a-namemementoaspan-classcodeitem-id1050mementospan

One more example. I wish to sync my VS Code settings between two computers.

You can sync your settings and keybindings via an extension, or go the dropbox route by syncing your ~/.vscode/extension and user data directory. You can check out this issue which looks at the possibility of bringing better sync support across machines to the core #2743

Workspace settings are meant to be checked in to your project, that's how you would sync them.

You told also that you don't use a workspace settings. I use it. I have different settings in different projects. In one I have tab space set to 4, in other - on 2. In some I have one settings for plugin, in another - I use different settings.

I suggest looking into http://editorconfig.org/ for this, it's a much portable and more elegant solution imo.

Workspace settings is useful, even if you don't use it personally.

Of course, that's why they're there.

---

If your issue is the python extension writing workspace settings, feel free to uninstall it, improve it, fork it, install another one or write your own.