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
Add go to definition support for dot sourced file paths #17
When peek definition or go to definition are used on a dot sourced file nothing happens. This is currently the same behavior that happens on built-in commands where the source file can't be found.
Should peek and go to definition bring the user to the very beginning of the dot sourced file when those features are used?
changed the title [-]Should definition support work on dot sourced files?[/-][+]Add go to definition support for dot sourced file paths[/+]on Nov 16, 2015
I'd like to start working on this. I won't be very quick, but seeing as it has been untouched for over 2 years that should not be a big problem.
I have a question about the desired behavior. It's simple if the dot sourced script is a full path, however let's assume that we have . ./SomeScript.ps1 in our file. SomeScript could be anywhere depending on the working directory or the Set-Locations that happened during execution. Should we simply try to locate the script relative to the one that's currently being edited as a "best guess" and move on if it isn't there?
So full paths and paths that resolve correctly from the current location PSES is at is probably good enough for now - and I think a lot of folks would be happy to see this!
We should be able to at least handle $PSScriptRoot in a dot sourced path or this feature will be kind of worthless. 95% of the dot sourcing I do is either with $PSScriptRoot directly or a path relative to it.
Activity
daviwil commentedon Nov 16, 2015
This is definitely a good idea, will add it for 0.2.
[-]Should definition support work on dot sourced files?[/-][+]Add go to definition support for dot sourced file paths[/+]dee-see commentedon Dec 31, 2017
I'd like to start working on this. I won't be very quick, but seeing as it has been untouched for over 2 years that should not be a big problem.
I have a question about the desired behavior. It's simple if the dot sourced script is a full path, however let's assume that we have
. ./SomeScript.ps1in our file.SomeScriptcould be anywhere depending on the working directory or theSet-Locations that happened during execution. Should we simply try to locate the script relative to the one that's currently being edited as a "best guess" and move on if it isn't there?TylerLeonhardt commentedon Jan 1, 2018
I think that's the correct approach.
There will be some scenarios where we will be unable to find the file like in this example:
. "$myComplexPath/SomeScript.ps1"If
myComplexPathis not set correctly at the time of "go to definition", we have no choice but to fail gracefully (aka do nothing).TylerLeonhardt commentedon Jan 1, 2018
So full paths and paths that resolve correctly from the current location PSES is at is probably good enough for now - and I think a lot of folks would be happy to see this!
rkeithhill commentedon Jan 1, 2018
We should be able to at least handle
$PSScriptRootin a dot sourced path or this feature will be kind of worthless. 95% of the dot sourcing I do is either with$PSScriptRootdirectly or a path relative to it.dee-see commentedon Jan 1, 2018
Alright sounds good, thanks. I'll give it a go.
Fix #17: Add go to definition support for dot sourced file paths (#786)
Merge pull request PowerShell#17 from aeschli/fix-languageid
Merge pull request PowerShell#17 from TylerLeonhardt/working-textdocu…