[FEATURE] Sync Favorite Projects via Gist

[alefragnani]

I finallu could play a little with the Authentication API and octokit, and wow! Really simple to use. I think the approaches below could be fairly easy to use, on a users perspective

The simplest way

Step 1. The user toggles a setting to say "Use GitHub Gists to store your projects", and that's it.

The extension will take care of creating a new secret gist with a yet to be defined name (something like VSCode - Project Manager Extension - Projects), and store a projects.json file there

The complex way

Step 1. The user toggles a setting to say "Use GitHub Gists to store your projects"
Step 2. The user defines the name of the Gist to be used

The extension will take care of creating a new secret gist with the name provided by the user (if not available yet) and store a projects.json file there.

This scenario is useful if the user would like to share the projects between Stable and Insiders release, just like the projectsLocation setting that already exists today

Because I can use Authentication API, there is no need to use Token, Gist ID or something more complex (like Settings Sync apparently still uses).

Deliberation: Use Simplest way

Originally posted by @alefragnani in #431 (comment)

[PhungXuanAnh]

Can you permit define favortie projects in settings of vscode, so it can be sync via vscode sync feature, thanks !

[alefragnani]

Hi @PhungXuanAnh ,

The "native" settings sync is being tracked in #431, but it still depends on the VS Code team to publish an API.

Hope this helps

[eddieparker]

Dumb question: any reason it has to be by gist, and not some other method? I'd feel better storing it even in my Google Drive account or something that a github gist lest my work-related workspaces leak.

[alefragnani]

Hi @eddieparker ,

The reason to use Gist is simply because VS Code itself already provided an authentication framework for GitHub, so it would be simpler.

But, there is no reason why it wouldn't exist a Google Drive too, so feel free to open a new issue for that.

Hope this helps

[alefragnani]

Hi,

I wonder, would be a good alternative to store the projects directly in the Settings, instead of the projects.json file (or Gist, in this case)?

Sure, for those that have a huge list of projects and/or don't like to have a lengthy settings file, this may be a no no. But I still think it could be a good alternative for some users.

But, I wound't combine the approaches. I mean, the user should choose which one to use. Simply because the extension needs to know where to save new projects, and also to avoid duplicates.

What do you think?

[eddieparker]

I like this. The less external reliance the better, as that introduces fragility. It also would "just work".

FWIW, I sorta solve the "lots of projects" by 'namespacing' my projects with a dot, so I have things like "work.project1", "work.project2", "dropbox.project1", etc. So even if I have a lot of projects, they're grouped in such a way that I can gloss over the ones I don't care about right now.

(I should really make a feature request for a 'tree view' based on folders/namespaces or something... :) )

[alefragnani]

Hi @eddieparker ,

Thanks for the feedback. I'm glad to know it will be useful.

About the organization feature you asked, have you tried the Tags feature (https://github.com/alefragnani/vscode-project-manager#project-tags---view-and-filter)? You can organize your projects by Tags, have a tree view like setup and even show/hide projects based on its Tags.

Hope this helps

[maxloo2]

I have been a long time user of Project Manager and I have been waiting for this feature for years! I use vscode on multiple machines and I make changes to the list quite frequently, currently I uses Notion to store the content of the JSON, it would be greatly convenient to not have to worry about external tools or platforms, just plain vscode and its one settings.json.

I have a bunch of remote machines and vscode is already storing all the IPs and machine types in this remote.SSH.remotePlatform object, I don't think having a nother projectManager.savedProjects array would be too much.