-
Notifications
You must be signed in to change notification settings - Fork 29.3k
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
[Getting Started] Provide when clauses for workspace tags #121778
Comments
Via @chrisdias: Workspace tagging happens in The way config/file extension recommendations work, using file patterns, could be more generic. |
Discussed w/ @kieferrm, considering modifying this to instead give priority to walkthroughs based on files present in workspace. So a TS walkthrough might be top-of-list when |
For many cases we would duplicate the signals that extensions use to get activated. This could also the existing signal for when a language extension activated because of files in a workspace – combining the |
Scoped this down to be getting started specific. With next insiders, walkthroughs will be able to declare a |
@JacksonKearl - for C++, our scenario is that we would change the steps within the walkthrough depending on workspace files (example: if CMakeLists.txt is present, we show the step to install CMake Tools). Should we achieve this by creating separate walkthroughs (one that has the Install CMake Tools step, one that doesn't) and using the featuredFor property? Or would that end up showing both versions of the walkthrough, one is just ranked higher? |
Yes, they would both show up with different ranks. Would it be possible to note in the step's description that the step is only relevant to folks using CMake? |
@JacksonKearl the featuring is a nice feature to highlight walkthroughs. Could we also address the need for C++ and for other walkthroughs that need to hide/show steps based on workspace/environment in the same issue, or should I file a new one? |
I think it would be a much better experience to hide/show steps based on if there's a CMakeLists.txt rather than showing all steps and updating the descriptions. The fewer steps in a walkthrough, the better. It's not just that we'd add a step if CMakeLists.txt is present, there are a few steps we'd hide. |
What's the best way to verify this? |
Using getting started sample, https://github.com/microsoft/vscode-extension-samples/blob/e84ecbf93b11c50f0ad673f8e171769f4deab787/getting-started-sample/package.json#L33, add a A couple known issues: if it's a very large project we may not find the file (the search is cancelled after a short timeout to not cause perf issues), and this is only evaluated on opening the folder for the first time (adding the file in a session will not cause the star to appear) |
@JacksonKearl - I'm just catching up on this. Is the featuredFor property available? |
To make walkthroughs more contextual to the currently open project, they should to be aware what kind of files/packages are in the project.
One of the best (there might be others) existing signals VS Code offers are workspace tags. If they would be available in
when
clause context, walkthroughs (and other UI elements) could adapt to that to show additional extensions, settings or specialized features.cc @jureid @JacksonKearl
The text was updated successfully, but these errors were encountered: