"Projects" and "Multi-root Workspaces" Strategy



First I really like the move to a local IDE using Visual Studio Code.

What I currently do not understand is the strategy Particle Workbench uses with Particle Projects: It forces the creation of a Multi-root Workspace which is named after the Particle Project and the only project folder inside is again a root folder named after the Particle Project.
Further the Particle Workbench does not work with the workspace in the way that it supports multiple project folders/Particle Projects which is what I understand the Multi-root Workspace is intended for.
I think it’s due to the strategy that all the particle properties (like firmwareVersion, targetPlatform) are stored at the workspace level (<workspace>.code-workspace) and not at the project level (<project>/.vscode/settings.json).

In my opinion this strategy also causes some confusion with existing VS-Code users because normally you open VS-Code at a folder to work on that project. For a Particle Project (even if ist just one) you have to open VS-Code via the workspace file inside the project folder.


thanks for the feedback :+1:

we went the current approach thinking we’d gain more predictability around configuration management while retaining the option to pull in additional directories on the user’s behalf and generally have more flexibility overall.

can you tell me more about how you use vscode workspaces in general? how do you envision workspaces working for the workbench? or are you suggesting they aren’t even needed?


I actually seldom use vscode workspaces. But for the Particle Workbench I wanted to use a vscode workspace for multiple Particle Projects. Concretely I wanted the three of my mesh Particle Projects (One project for Argon Gateway, One project for a Xenon Sensor Node, One project for a Xenon Actor Node) in one vscode instance to simply work on all of them from one workspace.


in that scenario what, if any, settings do you anticipate needing to manage at the workspace level?


I have not fully thought this trough, but I think per default all particle settings (firmwareVersion, targetPlatform, targetDevice) should be at the project folder level. The only one that I see could make sense to be able to keep in sync over all the project and therefore at the the workspace level is the firmwareVersion, but its already more an optimization that the default.


thanks. assuming this approach, what would you expect the Particle: Cloud Compile command to do? likewise, what would expect to see when invoking “Terminal > Run Task…” from VSCode’s main menu?


I had some ideas, but to not simply relay on my two cents, I checked what existing extensions which have already adopted the multi-root workspace do:

Particle: Cloud Compile similar to Python: Run All Unit Tests or Python: Select Interpreter

As soon as you are in a multi-root workspace an additional selection is shown to pick for which project folder you want to execute the command:

For the tasks in a multi-root workspace all the tasks are collected and the location of tasks is indicated by a folder name suffix.


thanks for poking at this with me :pray:

i’ll try to play some more with that model and see how things work out over here.

last question: just to confirm, you don’t find those additional UX hurdles (small as they may seem) overly burdensome or confusing?


The additional step does only appear when you have more than one project folder in the multi-root workspace. So for me this additional UX steps do not seem burdensome or confusing but rather a logical consequence of having more than one project folder, but I’m not a UX expert.


@bittailor, I agree completely. The multi-root workspace makes a lot more sense functionally IMO.


@bittailor @peekay123 I agree completely. The multi-root workspace makes a lot more sense functionally IMO.