You may show one of those scripts. You may have a missconception about how a script works.
If you only have function definitions in your scripts that’s expected. Anyway you could run them “scoped” for your current console session with “dot sourcing”. Then the contained functions exist in your current scope.
Here you can read more about:
Again … when you only have function definitions in your scripts that’s expected. You can add a param block diorectly to a script just like you’d do for a function. Then it will process provided parameters just like a function.
And once again … you have a missconception about how scripts work in your head. Remove the first and the last line of code in your script and name it *.ps1. Then you can run it like a function providing parameter values to it.
Update: I tried your thing with the Get-ChildItem in the .psm1 file and it works!!!
Is it safe to say this is best practice for modules ?
ModuleName # Folder
ModuleName.psm1 # Module file
ModuleName.psd1 # Manifest file
Function.ps1 # Next .ps1 script
Function2.ps1 # Next .ps1 script
Function3.ps1 # Next .ps1 script
I actually don’t know if it’s best practice. I just know that it makes it easier for me to maintain a module with more than just 2 or 3 functions in it. And I know some people do it this way.
You may read more about best practice for PowerShell here:
And again … at the end of the day it depends on your job and the requirements and maybe your team or your department or your company. Some companies or IT departments have a set of rules you may follow or you create some for yourself if you’re lucky enough to be in such a position. Especially when there are other colleagues working with your code it is nice when you make their work as easy as possible.