Imho, source has an interesting usability problem. And not the deliberate one of source being a parser #include, but a more ingrained one: where should relative paths be relative to?

In interactive mode, source should be cwd relative. This is the current behavior of source; if I do source foo.nu, then this runs foo.nu from the lookup path in the current context.

I'm not sure of the exact lookup path, but a bit of testing shows that it's $nu.history-path | path dirname | path join "scripts" and cwd.

When used as a scripting language, though, source really would like to be source-relative, like #[path = "{}"] mod_Rust, #include "{}"_C, import from "{}"_JS, etc.

Even more fun is that if I have e.g. source git-completions.nu in my $nu.config-path script and a git-completions.nu in my scripts file, then the scripts directory script gets sourced... unless my startup directory happens to have a git-completions.nu in it as well, in which case that one is used first.

But the real problem is that if I write some larger nushell script that I want to break into multiple files, I'm now restricting what cwds it can be run in, because all source commands are parser-cwd-relative, and all nu commands are block-cwd-relative, and there's no way to get a this-file-relative path.

In bash, you can do something like source "$(dirname "$0")"/helper.sh to source a sibling file. There is no equivalent for nushell that I can find.

So I have a proposal: make source use file-relative rather than cwd-relative lookup (while still falling back to looking in scripts). Imho this brings it more inline with other compiled languages. Interactive mode would just say that the line editor file is "in" cwd to retain the current interactive behavior.

.....and now I'm seriously considering whether we would want #pragma once.....