Commit 85ed2d4

- Functions for importing public and private functions from other projects into a ModuleBuild project

**Author:** [Zachary Loeber](https://www.the-little-things.net)

All base project documentation changes should be made against the .\build\docs\Additional markdown files. These will populate and overwrite existing document files within the .\docs folder at build time. Additionally, you should update the .\build\docs\ReadTheDocs markdown files. Note that each folder becomes its own section within ReadTheDocs and its own folder within the .\docs directory.

While any text editor will work well there are included task and setting json files explicitly for Visual Studio Code included with this project. I used VS Code Insiders edition but standard edition should be fine as ewll. The following tasks have been defined to make things a bit easier. First access the 'Pallette' (Shift+Ctrl+P or Shift+Cmd+P) and start typing in any of the following tasks to find and run them:

The plaster manifest file gets automatically recreated at build time so all you need to do is update the plasterparams.ps1 and/or plastercontent.ps1 in the plaster directory to include any required changes you need to make.

The plaster scaffolding files are largely standard files. But there are some template exceptions that you should be careful not to overwrite (any of the files that dynamically replace content from plaster input at creation time).

There are many items which are possible and should probably be added to this project. Here are a few thoughts on ones I'll probably get addressed sooner or later. I'm open to suggestions or pull requests.

- ~~Create functions to pull functions from another module (function only) and recreate them in the current module project directory would be cool.~~

- Appveyor integration

- Automatically generate module documentation with PlatyPS

- Helper functions to import existing project private and public functions into your ModuleBuild based project

Firstly, this module uses everything it creates in its own build process. Since this module is only mildly more complex than a simple script module that works out perfectly.

Aside from the handful of helper functions there is an included 'plaster' folder that includes a customized version of the module of the same name and a manifest folder named ModuleBuild. This ModuleBuild folder contains a scaffold directory structure used to create your projects. The questions asked as well as the actions taken when copying over the scaffold folder items are both contained in the root of the plaster directory in 'plastercontent.ps1' and 'plasterparameters.ps1' and are made into the plaster manifest file at build time.

The scaffolding itself is mostly a big invoke-build script.

**Note:** *Much of the ModuleBuild initial settings are not set in stone. If you do make changes to something like the included directories, or other settings which you would like to ensure others have access to when building your project you will have to update them in build\YourModuleName.buildenvironment.ps1*

8. Build your project with .\Build.ps1 (or in VS Code Ctrl+Shift+B)

9. If you have ReadTheDocs integration enabled make sure to re-organize the generated mkdocs.yml to be ordered how you like before pushing your code to github.

Once you have attained your API key you will need to update your build configuration file with it. From witin your project root directory do the following:

Assuming you have a valid NugetAPI key defined and your PowerShell manifest file has everything the gallary requires then this build step will automatically update the the upload the recent release directory module to the PowerShell Gallery for you.

To start working on your next release (or roll back to a prior release) you will need to update the version of your module. This is easily done:

It should be noted that performing the InstallAndTestModule build step is a bit superfluous as that gets done prior to uploading to the PSGallery as well. Also, you usually will be working on a release/build a bit before going straight to releasing to the gallery so I generally don't recommend doing everything in one fell swoop like this.