Skip to content
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

Canonical way to resolve folder in scoped ${workspaceFolder:<folder>} variables #198195

Closed
OmeGak opened this issue Nov 14, 2023 · 5 comments
Closed
Assignees
Labels
feature-request Request for new features or functionality tasks Task system issues

Comments

@OmeGak
Copy link

OmeGak commented Nov 14, 2023

I was surprised to find that VSCode provides no canonical way to resolve workspace folder when substituting ${workspaceFolder:<folder>} variables. This leaves how to resolve the scoped ${workspaceFolder} variable up to extension authors, clearly leading to inconsistent behavior (microsoft/vscode-python#22452). In that case the confusion was around named folders in multi-root workspaces.

It doesn't help that the official documentation remains ambiguous as to how scoped ${workspaceFolder} variables should be resolved. For instance, here, the documentation says nothing about the name attribute in workspace folders. Here, the documentation states that the name attribute in workspace folders is for display purpose in the Explorer. However, here, the documentation implies that the canonical way to resolve variables is as it happens in Task configurations.

Then, if a workspace folder is named, this task will fail:

"echo ${workspaceFolder:<workspace-folder-path-basename>}"

While this one will work:

"echo ${workspaceFolder:<workspace-folder-name>}"

Seeing that the behavior in VSCode is far from obvious, it may be worth to:

  • Provide a canonical way to resolve scoped workspace folder variables so that the behavior matches between VSCode and extensions. Could this be a resolveFolder() function in the WorkspaceFolder class?
  • Clarifying here that scoped ${workspaceFolder} variables are resolved with either their explicitly set name or with their path basename.
  • Clarifying here that the name attribute in workspace folder is not used only for display in Explorer but also to resolve scoped ${workspaceFolder} variables.

/cc @karrtikr, who fixed microsoft/vscode-python#22452.

@bpasero
Copy link
Member

bpasero commented Nov 14, 2023

I have unfortunately no clue what this ask is about, maybe some of the assignees can chime in.

@connor4312
Copy link
Member

connor4312 commented Nov 14, 2023

For instance, here, the documentation says nothing about the name attribute in workspace folders

From the docs you linked, it says "By appending the root folder's name to a variable (separated by a colon), it is possible to reach into sibling root folders of a workspace. Without the root folder name, the variable is scoped to the same folder where it is used."

My reading of the following two documentation links does not contradict that; the first link is the canonical source.

Clarifying here that the name attribute in workspace folder is not used only for display in Explorer but also to resolve scoped ${workspaceFolder} variables.

Sure, a cross-link would make sense. PRs welcome for that 🙂

Provide a canonical way to resolve scoped workspace folder variables so that the behavior matches between VSCode and extensions. Could this be a resolveFolder() function in the WorkspaceFolder class?

Sounds like this issue is mainly about having an API to resolve variables for extensions. I think that's @alexr00's domain. Though people have already written npm packages to do this, such as https://www.npmjs.com/package/@c4312/vscode-variables

@connor4312 connor4312 assigned alexr00 and unassigned connor4312 Nov 14, 2023
@sandy081 sandy081 removed their assignment Nov 15, 2023
@meganrogge meganrogge added feature-request Request for new features or functionality tasks Task system issues labels Nov 15, 2023
@vscodenpa vscodenpa added this to the Backlog Candidates milestone Nov 15, 2023
@vscodenpa
Copy link

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

@vscodenpa
Copy link

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

@vscodenpa
Copy link

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

@vscodenpa vscodenpa closed this as not planned Won't fix, can't repro, duplicate, stale Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality tasks Task system issues
Projects
None yet
Development

No branches or pull requests

8 participants