[Feature Request]: Convert `tools` folder into one or multiple PowerShell modules

[AlexanderSehr]

Description

To ease the usage & structure of our tools folder, I'd propose to convert it into one or multiple PowerShell modules with a proper structure like

To ease the usage & structure of our tools folder, I'd propose to convert it into one or multiple PowerShell modules with a proper structure like

To ease the usage & structure of our tools folder, I'd propose to convert it into one or multiple PowerShell modules with a proper structure like

• private/ (inner helper functions)

• public/ (exported functions - i.e. can be used from the outside)

• src/ (e.g. templates)

• modulesName.psd1

  ```PowerShell @{ # Script module or binary module file associated with this manifest. RootModule = 'ModuleName.psm1' # Version number of this module. ModuleVersion = '0.1.0' # Supported PSEditions # CompatiblePSEditions = @() # ID used to uniquely identify this module GUID = '807456f1-947d-43af-9b4d-49d13f593130' # Author of this module Author = 'CARML' # Company or vendor of this module CompanyName = 'Microsoft' # Copyright statement for this module Copyright = '(c) ServicesCode. All rights reserved.' # Description of the functionality provided by this module Description = 'Automatically generate new CARML modules using the Azure API & docs.' # Minimum version of the PowerShell engine required by this module # PowerShellVersion = '' # Name of the PowerShell host required by this module # PowerShellHostName = '' # Minimum version of the PowerShell host required by this module # PowerShellHostVersion = '' # Minimum version of Microsoft .NET Framework required by this module. This prerequisite is valid for the PowerShell Desktop edition only. # DotNetFrameworkVersion = '' # Minimum version of the common language runtime (CLR) required by this module. This prerequisite is valid for the PowerShell Desktop edition only. # ClrVersion = '' # Processor architecture (None, X86, Amd64) required by this module # ProcessorArchitecture = '' # Modules that must be imported into the global environment prior to importing this module # RequiredModules = @() # Assemblies that must be loaded prior to importing this module # RequiredAssemblies = @() # Script files (.ps1) that are run in the caller's environment prior to importing this module. # ScriptsToProcess = @() # Type files (.ps1xml) to be loaded when importing this module # TypesToProcess = @() # Format files (.ps1xml) to be loaded when importing this module # FormatsToProcess = @() # Modules to import as nested modules of the module specified in RootModule/ModuleToProcess # NestedModules = @() # Functions to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no functions to export. FunctionsToExport = @() # Cmdlets to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no cmdlets to export. CmdletsToExport = @() # Variables to export from this module VariablesToExport = '*' # Aliases to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no aliases to export. AliasesToExport = @() # DSC resources to export from this module # DscResourcesToExport = @() # List of all modules packaged with this module # ModuleList = @() # List of all files packaged with this module # FileList = @() # Private data to pass to the module specified in RootModule/ModuleToProcess. This may also contain a PSData hashtable with additional module metadata used by PowerShell. PrivateData = @{ PSData = @{ # Tags applied to this module. These help with module discovery in online galleries. Tags = @('CARML') # A URL to the license for this module. # LicenseUri = '' # A URL to the main website for this project. ProjectUri = 'https://aka.ms/CARML' # A URL to an icon representing this module. # IconUri = '' # ReleaseNotes of this module # ReleaseNotes = '' # Prerelease string of this module # Prerelease = '' # Flag to indicate whether the module requires explicit user acceptance for install/update/save # RequireLicenseAcceptance = $false # External dependent modules of this module # ExternalModuleDependencies = @() } # End of PSData hashtable } # End of PrivateData hashtable # HelpInfo URI of this module # HelpInfoURI = '' # Default prefix for commands exported from this module. Override the default prefix using Import-Module -Prefix. DefaultCommandPrefix = 'Carml' } ```
• moduleName.psm1

  ```Powershell [cmdletbinding()] param() # Load central config file; Config File can be referenced within module scope by $script:CONFIG Write-Verbose 'Load Config' $moduleConfigPath = Join-Path $PSScriptRoot 'ModuleConfig.psd1' $script:CONFIG = Import-PowerShellDataFile -Path (Resolve-Path ($moduleConfigPath)) $script:repoRoot = (Get-Item $PSScriptRoot).Parent.Parent.Parent $script:moduleRoot = $PSScriptRoot $script:src = Join-Path $PSScriptRoot 'src' $script:temp = Join-Path $PSScriptRoot 'temp' Write-Verbose 'Import everything in sub folders public & private' $functionFolders = @('public', 'private') foreach ($folder in $functionFolders) { $folderPath = Join-Path -Path $PSScriptRoot -ChildPath $folder If (Test-Path -Path $folderPath) { Write-Verbose "Importing from $folder" $functions = Get-ChildItem -Path $folderPath -Filter '*.ps1' -Recurse foreach ($function in $functions) { Write-Verbose (' Importing [{0}]' -f $function.BaseName) . $function.FullName } } } $publicFunctions = (Get-ChildItem -Path "$PSScriptRoot\public" -Filter '*.ps1').BaseName Export-ModuleMember -Function $publicFunctions ```
• ModuleConfig.psd1

  ```Powershell @{ #region general ... #endregion } ```

• readme.md

With that, we could remove 'inner/helper' functions from the scripts and move them instead as private functions into the 'private' folder.

We'd further need to adjust the current loading of the functions in the pipeline and replace it with the import of the Module.

This is implemented in an iterative approach with the following PRs:

• [ ] #2181

[AlexanderSehr]

Should dicusss the PR some time and make a plan to get this done as quick as possible

[eriqua]

@AlexanderSehr should these efforts be put in C# redevelopment?

[AlexanderSehr]

@AlexanderSehr should these efforts be put in C# redevelopment?

Hey @eriqua, ultimately no. The one function which is currently under consideration is the Set-ModuleReadMe function. However, it is only 1 of 58 (+ inner functions) scripts in the 'utilities' folder, or 1 of 23 (+ inner functions) of the 'tools' folder. So we could instead simply not start with the Set-ModuleReadMe function (even though this PR was ready weeks ago. Dumped it just recently as it ran for so long that it became stale).

[AlexanderSehr]

I can, if you agree, start with the other ones over

[AlexanderSehr]

Un-assigned myself as we need to start over anyways and given the previous attept I don't think this will be something we merge any time soon