You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Updated all functions with prefix. Added back functions that where removed from ModuleBuildToolsTemp. Bumped version of ModuleBuildToolsTemp. Updated build scripts to fix issues with building modules that are also a dependency
FunctionTemplates="src\templates"# Location of function template files (*.tem)
62
62
63
63
# If you will be publishing to the PowerShell Gallery you will need a Nuget API key (can get from the website)
64
-
# You should NOT enter this key here but rather manually enter it in the ModuleBuild.buildenvironment.json file with: Set-MBTBuildEnvironment -NugetAPIKey '<key>'
64
+
# You should NOT enter this key here but rather manually enter it in the ModuleBuild.buildenvironment.json file with: Set-MBBuildEnvironment -NugetAPIKey '<key>'
- Added ability to pull in some basic information about an existing module manifest files when running initialize-modulebuild.
35
+
- Added ability to pull in some basic information about an existing module manifest files when running Initialize-MBModuleBuild.
36
36
- Fixed ReadTheDocs generation issues by updating the template to include build\docs\ReadTheDocs in the initialization process.
37
37
- Eliminated any customization requirements within the modulename.build.ps1 script to help pave the way for easier modulebuild upgrades to projects.
38
38
- Removed some superfluous code in the base build environment script around the RequiredModules variable.
39
39
40
40
## Version 0.2.2
41
41
42
42
- Updated vscode tasks.json to fix depreciated syntax.
43
-
- Fixed `-Force` switch processing on Add-PublicFunction to still create the function if the provided name is detected as plural.
43
+
- Fixed `-Force` switch processing on Add-MBPublicFunction to still create the function if the provided name is detected as plural.
44
44
- Fixed [cleanup script modulebuild execution issue](https://github.com/zloeber/ModuleBuild/issues/5) by separating out the postbuildtask into its own Invoke-Build code block (I had done this a while ago and never rolled up the changes into the Plaster template).
45
45
- Fixed a glaring issue with the PlatyPS output where any Guids were 00000000-0000-0000-0000-000000000000 instead of the actual module manifest Guid [reported via issue #6](https://github.com/zloeber/ModuleBuild/issues/6). This happens because we build the module help from the psm1 load of the module in memory, not the psd1 file as that psd1 manifest gets recreated at build time with the appropriate exported functions and such. Basically a chicken/egg scenario. For now we just manually replace the output markdown files with the correct Guid before moving on to the help file packaging.
- Removed plaster option to choose to combine the module source at build time (and simply made that behavior the default that can be changed later via Set-MBTBuildEnvironment -OptionCombineFiles $false)
60
+
- Removed plaster option to choose to combine the module source at build time (and simply made that behavior the default that can be changed later via Set-MBBuildEnvironment -OptionCombineFiles $false)
61
61
- Added option to run a code health report (via PSCodeHealth) against your public and private function directories prior to starting the build
62
62
- Added 'Module plugin' capability. This adds base functionality to the module project itself. The first included module plugin is the nlogmodule logging functionality.
- Fixed an issue with a null build environment variable causing dynamic parameters in Set-MBTBuildEnvironment to fail
88
+
- Fixed an issue with a null build environment variable causing dynamic parameters in Set-MBBuildEnvironment to fail
89
89
- Several small scaffolding clean ups.
90
90
91
91
## Version 0.1.1
92
92
93
-
- Removed prompts for the nuget api key when running initialize-modulebuild.
94
-
- Initialize-ModuleBuild now automatically runs the build environment powershell script for the first time to create the modulebuild json settings file.
93
+
- Removed prompts for the nuget api key when running Initialize-MBModuleBuild.
94
+
- Initialize-MBModuleBuild now automatically runs the build environment powershell script for the first time to create the modulebuild json settings file.
95
95
- More documentation.
96
96
- Fixed some minor scaffolding creation issues.
97
97
- Added a 'ForceInstallModule' setting to eliminate build prompt when running the install and test module build tasks when the module is already installed.
Copy file name to clipboardExpand all lines: build/docs/ReadTheDocs/Usage/1 - Initialization.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,13 @@
1
1
# Step 1 - Initialization
2
-
Simply download this project and run the Initialize-ModuleBuild exported function. You will be prompted for a destination folder and the rest of the project settings. The destination folder will be the home of your future project but is completely portable. This is simply a wrapper for a custom version of Plaster that calls a template file I created for the project. It is fairly simple to deconstruct and use plaster directly via invoke-plaster and pass all the parameters via command line if desired.
2
+
Simply download this project and run the Initialize-MBModuleBuild exported function. You will be prompted for a destination folder and the rest of the project settings. The destination folder will be the home of your future project but is completely portable. This is simply a wrapper for a custom version of Plaster that calls a template file I created for the project. It is fairly simple to deconstruct and use plaster directly via invoke-plaster and pass all the parameters via command line if desired.
Once this has been kicked off and all answers have been entered, the initialization of your new project directory will start. Several template files are copied out to appropriate locations. Additionally, the default module manifest file gets created.
@@ -17,7 +17,7 @@ Once this has been kicked off and all answers have been entered, the initializat
17
17
## Quick Start
18
18
With your new module folder all created there are several steps still left to take in order to make your new project more world class. There are several sections of the following documentation that go over fleshing out the module with public functions, building a release, testing things, out and starting another release. Here are some quick next step tips if you aren't feeling like reading all of that.
19
19
20
-
1. Add public functions, one per file, to .\src\public (You can use the ModuleBuild function 'Add-PublicFunction' for this task)
20
+
1. Add public functions, one per file, to .\src\public (You can use the ModuleBuild function 'Add-MBPublicFunction' for this task)
21
21
2. Update your default readme.md file at the root project directory
22
22
3. Update the about_ModuleName.help.txt file within .\build\docs\en-US
23
23
4. Doing ReadTheDocs integration? Cool, update .\build\docs\ReadTheDocs by creating folders representing sections and putting markdown files within them for the pages within those sections.
Copy file name to clipboardExpand all lines: build/docs/ReadTheDocs/Usage/10 - Converting To ModuleBuild.md
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -2,15 +2,15 @@
2
2
3
3
If you want to convert your existing module to a modulebuild based project then there are a few functions that have been created to help you along. These are a bit new and should be considered a feature in testing.
4
4
5
-
## Public Functions: Import-ModulePublicFunction
5
+
## Public Functions: Import-MBModulePublicFunction
6
6
7
7
Assuming your existing module is loadable it is pretty simple to determine public functions and then search through all of the module code for them. That is what this function will do. Once the public function has been found it will then (by default) attempt to insert the bare minimum comment based help necessary for PlatyPS to be able to autogenerate the module documentation and save the file into your ModuleBuild project public directory (as defined by your modulebuild project definition file).
8
8
9
9
This will not overwrite any files that exist by the same name.
Private functions within a module are infinately more tricky to isolate. But based on what is exported and what we find within the module source directory, it is not impossible to guess some of the private functions at least. That is what Import-ModulePrivateFunction command will do. It will always prompt you before importing any found top-level function (that isn't in the list of exported functions).
13
+
Private functions within a module are infinately more tricky to isolate. But based on what is exported and what we find within the module source directory, it is not impossible to guess some of the private functions at least. That is what Import-MBModulePrivateFunction command will do. It will always prompt you before importing any found top-level function (that isn't in the list of exported functions).
14
14
15
15
Like the public function import, this will not overwrite any files that exist in your public source directory.
16
16
@@ -20,8 +20,8 @@ So in order to convert an existing project to a modulebuild project you will fol
20
20
21
21
1. Initialize a new ModuleBuild project folder
22
22
2.~~**Build** the project (**and it will fail the first time**). This ensures that your modulebuild project settings have been exported at least once.~~
23
-
3. From your new modulebuild project folder run the Import-ModulePrivateFunction command against your existing module.
24
-
4. From your new modulebuild project folder run the Import-ModulePublicFunction command against your existing module.
23
+
3. From your new modulebuild project folder run the Import-MBModulePrivateFunction command against your existing module.
24
+
4. From your new modulebuild project folder run the Import-MBModulePublicFunction command against your existing module.
25
25
5. Add any required preload or postload code in src\other\preload.ps1 or src\other\postload.ps1
Copy file name to clipboardExpand all lines: build/docs/ReadTheDocs/Usage/2 - Make Your Module.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,9 @@ After the initialization has completed this directory should be all setup and 'b
6
6
7
7
Any exportable/public functions for your module should be dropped into the .\src\public folder. Ideally each function will be self contained with a file name that matches the function name. Any other private functions can be dropped into .\src\private.
8
8
9
-
You can easily add a new public function using templates of your own devising with the `Add-PublicFunction` command. To add a new public function with a rather bare template function run the following:
9
+
You can easily add a new public function using templates of your own devising with the `Add-MBPublicFunction` command. To add a new public function with a rather bare template function run the following:
The allowed template names are dynamically pulled directly from the module src\templates directory. Look in this folder for an example template and feel free to add more of your own to suit your project needs.
0 commit comments