Add go to definition support for dot sourced file paths

[kaylaerdmann]

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?

[daviwil]

This is definitely a good idea, will add it for 0.2.

[dee-see]

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?

[TylerLeonhardt]

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 myComplexPath is not set correctly at the time of "go to definition", we have no choice but to fail gracefully (aka do nothing).

[TylerLeonhardt]

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]

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.

[dee-see]

Alright sounds good, thanks. I'll give it a go.