Enable 'powershell.scriptAnalysis.settingsPath' to search project root in multi-root workspaces

[steakhutzeee]

Prerequisites

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

Summary

Hello,

as i can see, the option powershell.scriptAnalysis.settingsPath can only be set globally or per workspace.

I'm actually using multi-root workspaces and so i should edit the setting every time i switch the folder.

Could be possible to implement a way to search for the PSScriptAnalyzerSettings.psd1 file in the project root and so on, in order to have one different setting file per folder in a multi-root workspace?

Default value set in #2190 does nothing. Setting file is not read from any of my directories in the workspace.

Thank you!

Proposed Design

No response

[lewis-yeung]

Agreed. It will bring great convenience if this can be implemented.

[andyleejordan]

Oh is that what's going on. To be honest I've been meaning to investigate this setting because it looked broken to me...I was in a multi-root repo! Yes, we'll get this fixed. Probably the most backwards compatible algorithm is to check each folder as if it were root, stopping with the first found file (and starting with the first listed folder).

[andyleejordan]

Ok so I started working on this but:

Could be possible to implement a way to search for the PSScriptAnalyzerSettings.psd1 file in the project root and so on, in order to have one different setting file per folder in a multi-root workspace?

I'm not sure how viable this is. This specifically being per-workspace-folder PSSA settings. The extension is just one process for the whole workspace, which means one analysis service and therefore one PSSA being hosted. I think it's going to have to remain one PSSA settings file per workspace.

What I can fix is the ability to find that file in any (the first where it exists) of the workspace folders. Would that help? I checked and it as of now, if it's in the first workspace folder of a multi-root workspace, it's found. That just doesn't work if it's instead in a second or beyond folder.

I also tested just to be sure and unfortunately the syntax of ${workspaceFolder:<some named folder>} doesn't work in a workspace settings file.

[lewis-yeung]

The extension is just one process for the whole workspace, which means one analysis service and therefore one PSSA being hosted.

unfortunately the syntax of ${workspaceFolder:<some named folder>} doesn't work in a workspace settings file.

@andyleejordan So, I guess the limitation is that ${workspaceFolder:<folderName>} cannot be expanded as expected for path resolution in the VS Code extension, under the restriction of the singleton service, right? Anyway, thank you for trying to fix it.

[andyleejordan]

@lewis-yeung that's correct.

What I can fix is the ability to find that file in any (the first where it exists) of the workspace folders. Would that help? I checked and it as of now, if it's in the first workspace folder of a multi-root workspace, it's found. That just doesn't work if it's instead in a second or beyond folder.

Would this still be an improvement for you? If so I can get PowerShell/PowerShellEditorServices#2167 into the next release.

[lewis-yeung]

Would this still be an improvement for you? If so I can get PowerShell/PowerShellEditorServices#2167 into the next release.

Seems there is no perfect solution for the time being, but that would help somewhat, I think.

[andyleejordan]

While not perfect, a fix for this just made it into today's stable release, v2025.0.0. You can choose which workspace's PSSA settings file is used by ordering the workspaces, as it checks in order and uses the first found.