If B.ps1 would just dot-import A.ps1, it wouldn't work (because powershell parses classes before sourcing files). However, if there was:
C.ps1
. $PSScriptRoot/A.ps1
. $PSScriptRoot/B.ps1
both A and B would be happily imported. I've noticed such a pattern started occurring in the wild – A.ps1 and B.ps1 are never imported directly, but only through a C.ps1 "import wrapper". When using class A through such a wrapper, shelly currently does weird things:
Warns about unused imports of A.ps1 and B.ps1 in C.ps1.
Warns about indirect usage of B.ps1 in files that import only C.ps1 wrapper.
(Fortunately doesn't scream about unknown class [A] in B.ps1, but it should)
I have no idea what to do about it. It would be nice to detect such a pattern, disable stupid warnings, and perhaps emit a lint if dependent class is used without a wrapper.
For now, I think I'm going to just disable indirect-imports and unused-imports on classes.
Consider:
If B.ps1 would just dot-import A.ps1, it wouldn't work (because powershell parses classes before sourcing files). However, if there was:
both A and B would be happily imported. I've noticed such a pattern started occurring in the wild – A.ps1 and B.ps1 are never imported directly, but only through a C.ps1 "import wrapper". When using class
A
through such a wrapper, shelly currently does weird things:[A]
in B.ps1, but it should)I have no idea what to do about it. It would be nice to detect such a pattern, disable stupid warnings, and perhaps emit a lint if dependent class is used without a wrapper.
For now, I think I'm going to just disable indirect-imports and unused-imports on classes.
cc @m-kostrzewa @sodar