Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a Generate-QuickDocumentation or Create, or something... function #22

Open
EdLichtman opened this issue Oct 15, 2020 · 5 comments

Comments

@EdLichtman
Copy link
Owner

It should be _____-QuickDocumentation -NestedModule -CommandName. The idea is to auto-generate the documentation for a function. In order to get the Parameters and definition stuff I can start investigating the output of piping into | Get-Member using the following to obtain the Function itself:

(Get-Item -Path Function:$CommandName)

@EdLichtman
Copy link
Owner Author

$Attributes = ((Get-Command Add-QuickFunction).Parameters.Values | Select-Object -Property @{E={$_.Attributes};N='Attributes'} -First 1)

Alternatively, I could do a get-content regex search for "[ {rn]param((FIND PARAMETERS WITHIN THIS BLOCK)"

@EdLichtman
Copy link
Owner Author

EdLichtman commented Oct 15, 2020

This is the one:

(Get-Command $CommandName).Parameters.Values | Where-Object { -not ([Management.Automation.Cmdlet]::CommonParameters.Contains($_.Name) -or [Management.Automation.Cmdlet]::OptionalCommonParameters.Contains($_.Name))}

@EdLichtman
Copy link
Owner Author

Closing issue once I build up infrastructure.

Instead of self-rolling in will use ms supported open source module PlatyPS. Additionally I want core library to have no dependencies so I'll create QuickModuleCLI.AutoDocs as a module the required QuickModuleCLI as external dependency and PlatyPS.

Goal now is to focus on testing, and documentation of core module.

https://amp.reddit.com/r/PowerShell/comments/79ebx1/how_do_i_get_module_dependencies_to_auto_download/

@EdLichtman
Copy link
Owner Author

After having Tested out PlatyPS, it creates all NestedModule Functions And Aliases (If Applicable) into the Root Help Docs folder. So I'll have to first Find and confirm that QuickCommand Exists, and then attempt to edit the MD file at \QuickModuleCLI.AutoDocs\MarkDown.

When I'm ready to Export or Split QuickCommand, I'll find all the Commands that exist in the Nested Module and map them to the modules that exist in QuickModule.AutoDoc\MarkDown. I'll then Copy the files into the root\Help\Markdown folder of the Split Modules and build the XML documentation. Exported Module will be more challenging. I can't really split the documentation out, but in theory, Export is meant to be imported or shared, so I'll have to think of if it's even worth it to try to get the XML MAML documentation on Export.

Finally, if I split the Main Module and the Documentation Module, I'll have to consider what to do about Delete-QuickCommand. I can't really force an automatic relationship there, but perhaps I can spit out an error message or warning saying "Documentation exists for non-existent Command: X. Please run Sync-QuickModuleCLIAutoDocs

@EdLichtman
Copy link
Owner Author

On Import of the PSM1 I will run Sync-QuickModuleCLIAutoDocs I think. That's how I can automatically delete QuickModuleCLI documentation that's no longer relevant. Additionally, if you export a module, all you need are the AutoDoc Markdown files for that Module. Then, when you run SyncQuickModuleCLIAutoDocs, it'll automatically generate the ExternalHelp for you.

I'll need to change the # .ExternalHelp file import when exporting or splitting the module though, and when Importing the module again. Exporting should just be used for importing. Splitting can be shared amongst Coworkers as a full-fledged Module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant