VMware.Hv.Helper is unwieldy and could do with a refactoring

[thor]

trafficstars

In using the VMware.Hv.Helper we have come across a few bugs here and there, which we've tried to fix. However, working in the one enormous file that is VMware.Hv.Helper.psm1, we've often found it quite cumbersome.

Is there interest in doing all, or some, of the following:

• Split the script module into smaller files, preferably no longer than about 1-2K
• Use Merge-Script or similar to create one file for actual use/production
• Publish it to the PSGallery should there be interest in it

There are things we'd like to refactor in the helper, but with its current setup we'd rather just fork it entirely than try to merge things the way they are right now.

[CajunBard]

@thor,

I absolutely agree that the module is cumbersome to maintain in its current state. Consider me in favor of refactoring to multiple files. The concern of longer load times should also be top of mind. It seems you are already thinking that direction with the use of Merge-Script.

As for submitting to PSGallery, I'm in favor of it, but I need to reach out to my peers to understand the process better.

[thor]

Hi @freythman,

Thank you for replying. I'm enthusiastic of the thought of having a more end-user friendly VMware.Hv.Helper in the end. :relaxed:

I absolutely agree that the module is cumbersome to maintain in its current state. Consider me in favor of refactoring to multiple files. The concern of longer load times should also be top of mind. It seems you are already thinking that direction with the use of Merge-Script.

Yup. It wasn't something I was aware of before, but it affects it rather strongly.

As for submitting to PSGallery, I'm in favor of it, but I need to reach out to my peers to understand the process better.

Any particular part of it? I'd suggest coupling the repository with an AppVeyor pipeline, which would then automatically update the module in the PSGallery when tests are successful. You would have to fetch and store an API key, however.

I'm considering this very tentative split of the functions:

• Core (helpers, Get-ViewApiService, etc.)
• Pools
• Machines
• Farms

Then, to further simplify things, I'd like to move the documentation out of the module files and into Markdown, which is kept up-to-date with PowerShell/platyPS. In the end, I'd like to see if the objects need to be wrapped or if format definitions could do enough to limit functios to one-per objects rather than having to use different functions for human-readable information and the objects returned from the ExtensionData object.

What do you think?

Edit: it might be pertinent to move it into its own repository, considering how much functionality is in the one module?

[thor]

Hi again,

Bumping this with two questions:

• is this something that your peers were interested in or thought was an alright proposition?
• is the REST API something which will replace the Horizon View module in its current form and thus deprecate this?