Allow means to avoid adding an absolute Cwd path to the workspace settings

[cegekaJG]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.

Summary

Our team's repositories all track our .code-workspace files to make sure people are working with the same settings. However, we obviously can't include an absolute path in the powershell.cwd setting because we can't ensure it will be the same between users. Unfortunately, there seems to be no way to avoid this issue, and worst case, we keep having to remove the automatically appended setting.

Proposed Design

I can think of 3 ways to circumvent this problem:

1. Add an option that, when opening a file in PS-language, recursively scan in the file's directory for a workspace setting file, going up a folder if nothing could be found. If one is found, pick the workspace directory the file is located in, (choosing the nearest if there are nested folders) and use that as the Cwd for the session.
2. Add an option that reads the Cwd path from a different file that can be included in the .gitignore. You could enforce it to be located in the same directory as the workspace settings.
3. Add an option that doesn't write the Cwd path into the settings, and just caches them instead, prompting the user to specify a folder every time after the cache is cleared.

[andyleejordan]

Agreed, it's been bothering me too. It seemed like an okay solution at first but the fact that it has to be absolute makes it very terrible. I think we could go with #3. I'm imagining the setting would be left available, but the extension would never write to it; instead, if prompted to choose X of Y workspace folders, we'll remember which by using Code's extension data API (it just wasn't wired up at the time).

[JustinGrote]

@andyleejordan I think this would be fairly simply possible that, rather than storing in workspace settings, store in the workspaceState Memento of the extensionContext as a key.

https://code.visualstudio.com/api/references/vscode-api#ExtensionContext

This would persist across reloads, it would be user-specific (so different people can have different local CWD paths) and would function the same as CWD does now, though for good UX we will probably also want to expose what workspace is the currently active one in the Powershell language menu and offer a button to change it that ties to the existing command.

[andyleejordan]

From what I remember when originally implementing, using that was more difficult than anticipated as we hadn't plumped through the context at the time. However, I think we've since made the extension context more readily available to classes in the client, sooo yes this is probably doable pretty easily now! Up-for-grabs if you want to take a crack at it...I'm trying to figure out how not to have to just merge the revert PowerShell/PowerShell#20042 to fix #4668.

[andyleejordan]

So I looked back into saving that info, and it would go into globalState...which is fine except we'd have to build a whole way to reset that state if the user wanted to change their answer. Instead I decided to just stop writing to the cwd setting at all; opting to support named workspace folders.

[JustinGrote]

@andyleejordan in testing #4687 this works as expected, do you plan to have the pop up dialog set the workspace folder setting as a sort of "dont ask again", or is it expected that the pop up dialog will always be per-session and you have to manually set the setting if that's what you want? If so then may want to make sure this gets noted as a behavior change in the release notes.

[andyleejordan]

@JustinGrote I knew I was forgetting something. I'm not sure how to best handle that at the moment...I'm just going to through a comment about that in the prompt itself.