mirror of
https://github.com/nushell/nushell.git
synced 2026-10-28 17:05:03 +08:00
Bahex
27b7790c21
## Description
Currently, importing a module also imports its exported sub-modules.
```nushell
use std/dirs
dirs_ # completion triggered
# => dirs
# => dirs add
# => dirs drop
# => dirs goto
# => dirs next
# => dirs prev
# => dirs shells-aliases dexit
# => dirs shells-aliases enter
# => dirs shells-aliases g
# => dirs shells-aliases n
# => dirs shells-aliases p
# => dirs shells-aliases shells
```
This is unexpected (and really annoying).
Also, while it imports the sub-module's definitions, it does not run the
sub-module's `export-env` block.
With this PR:
```nushell
use std/dirs
dirs_ # completion triggered
# => dirs
# => dirs add
# => dirs drop
# => dirs goto
# => dirs next
# => dirs prev
```
To use the aliases, one just needs to `use std/dirs shells-aliases *`
## User-facing changes (Release notes)
Importing a module no longer implicitly imports its exported
sub-modules.
```nushell
export module foo {
export def bar [] {}
export module sub {
export def baz [] {}
}
}
use foo
foo bar # valid
foo sub baz # invalid, `sub` is not implicitly imported
```
To have your modules keep the old behavior, you will need to export the
modules contents explicitly:
```nushell
export module foo {
export def bar [] {}
export module sub {
export def baz [] {}
}
export use sub
}
use foo
foo bar # valid
foo sub baz # valid
```
> [!NOTE]
> `use`ing a module inside another module does *not* run the imported
module's `export-env` block.
> (See [`export-env` runs only when the use call is
evaluated](https://www.nushell.sh/book/modules/creating_modules.html#export-env-runs-only-when-the-use-call-is-evaluated))
> Thus, explicit `use`s as recommended above will not run `export-env`
blocks, which is inline with how the previous implicit imports worked.