You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enable module-wide symbol indexing and operations #394
We need to have a more robust and reliable method for indexing symbols across a module or modules within a workspace so that the following operations work as expected:
Nope, never had time. One thing I wanted to do was to create a "Project" subsystem for PSES which is able to index files in a way that will be semantically correct for the language and really efficient. It is a nontrivial amount of work. Maybe Patrick Meinecke (@SeeminglyScience) might want to look into it someday ;)
Coincidentally I've thought about this a lot over the last month or so. I think an ideal implementation would be being able to select a target psd1 file the same way the C# extension can select a target csproj.
Unfortunately even with that system, this is way more complex than it may seem on the surface. Ideally, this would work purely from static analysis. Realistically, we'd either have to enforce a standard way of loading functions from separate files or load the module and operate based on the state. And I have a hard time seeing the former as a real possibility.
Actually executing the module is the only way I see this working reliably but I think there are a lot of non-technical challenges with that. You'd have to communicate clearly that the simple act of opening a workspace might execute code, and it'd definitely have to be opt-in only.
I think workspace profiles are a really good first step into that space, and I wouldn't put too much time into thinking about this feature until that's implemented.
I dunno about relying upon module infrastructure. I know a few teams where I work that have a big hairball of scripts they dot source and don't use modules at all.
Couldn't we add a setting (or psproj.json file) where the user could have control over where we look for script files? Could even default to the entire repo with some preset excludes (**/node_modules, **/.git, etc). That doesn't address the "semantically correct" part which I believe means following the trail of dot-sourcing. But it would still be pretty darn nice.
Keith Hill (@rkeithhill) Yeah that makes sense. We could have it act more like the references code lens currently does but with a way to exclude (well, the references code lens would need to follow that exclusion as well obviously)
I wonder if the exclude setting should be part of a new static project file, or setting set in the workspace profile via a command like Set-EditorOption. If we go with the former it may be worth opening a discussion with the folks behind the non-PSES PowerShell focused editors.
That doesn't address the "semantically correct" part which I believe means following the trail of dot-sourcing. But it would still be pretty darn nice.
Yeah, I recently stripped out the AST inference code from PS Core and replaced all the private API calls with (slower) public ones as part of a revamp of my editor command module. Included in that logic is safe expression evaluation. If all goes well that would be very useful for implementing that (also for implementing find references for classes)
Edit: I definitely still think module specific logic should be implemented as well, especially to be able to handle things like private functions differently. But searching the whole workspace with an exclusion list should absolutely be implemented at least as a fall back.
Resolved in v3.8.0 (#1984, #1917) — workspace PowerShell files are scanned and per-file references cached for module-wide definition/reference (SymbolsService.ScanWorkspacePSFiles). Closing as completed.
Activity
TylerLeonhardt commentedon Jan 12, 2018
Did you make any progress on this one?
daviwil commentedon Jan 12, 2018
Nope, never had time. One thing I wanted to do was to create a "Project" subsystem for PSES which is able to index files in a way that will be semantically correct for the language and really efficient. It is a nontrivial amount of work. Maybe Patrick Meinecke (@SeeminglyScience) might want to look into it someday ;)
SeeminglyScience commentedon Jan 12, 2018
Coincidentally I've thought about this a lot over the last month or so. I think an ideal implementation would be being able to select a target psd1 file the same way the C# extension can select a target csproj.
Unfortunately even with that system, this is way more complex than it may seem on the surface. Ideally, this would work purely from static analysis. Realistically, we'd either have to enforce a standard way of loading functions from separate files or load the module and operate based on the state. And I have a hard time seeing the former as a real possibility.
Actually executing the module is the only way I see this working reliably but I think there are a lot of non-technical challenges with that. You'd have to communicate clearly that the simple act of opening a workspace might execute code, and it'd definitely have to be opt-in only.
I think workspace profiles are a really good first step into that space, and I wouldn't put too much time into thinking about this feature until that's implemented.
rkeithhill commentedon Jan 12, 2018
I dunno about relying upon module infrastructure. I know a few teams where I work that have a big hairball of scripts they dot source and don't use modules at all.
Couldn't we add a setting (or psproj.json file) where the user could have control over where we look for script files? Could even default to the entire repo with some preset excludes (**/node_modules, **/.git, etc). That doesn't address the "semantically correct" part which I believe means following the trail of dot-sourcing. But it would still be pretty darn nice.
SeeminglyScience commentedon Jan 12, 2018
Keith Hill (@rkeithhill) Yeah that makes sense. We could have it act more like the references code lens currently does but with a way to exclude (well, the references code lens would need to follow that exclusion as well obviously)
I wonder if the exclude setting should be part of a new static project file, or setting set in the workspace profile via a command like
Set-EditorOption. If we go with the former it may be worth opening a discussion with the folks behind the non-PSES PowerShell focused editors.Yeah, I recently stripped out the AST inference code from PS Core and replaced all the private API calls with (slower) public ones as part of a revamp of my editor command module. Included in that logic is safe expression evaluation. If all goes well that would be very useful for implementing that (also for implementing find references for classes)
Edit: I definitely still think module specific logic should be implemented as well, especially to be able to handle things like private functions differently. But searching the whole workspace with an exclusion list should absolutely be implemented at least as a fall back.
Merge pull request PowerShell#394 from PowerShell/kapilmb/fix-quick-fix
andyleejordan commentedon Jun 15, 2026
Resolved in v3.8.0 (#1984, #1917) — workspace PowerShell files are scanned and per-file references cached for module-wide definition/reference (
SymbolsService.ScanWorkspacePSFiles). Closing as completed.Drafted by GitHub Copilot (Claude Opus 4.8) at Andy Jordan (@andyleejordan)'s request.