Consider using module builder pattern to halve module import time

[bergmeister]

Whilst I like posh-git, it also adds a big portion (500-1000ms) to the load time of PowerShell because of the call to Import-Module posh-git in the $PROFILE.
One possibility of halving (I've done an experiment) the module import time, is to have all the source code in one monolithic file instead of dot sourcing them in. This does not mean the source code of the module needs to be stored in a monolithic file but one would need to add a build process before publishing the module, one does not need to re-invent the wheel though as one could e.g. use the ModuleBuilder module for that.
Would you be happy with that?
Or would it be useful to look into alternative ways of having a more lightweight module import (some user's might not use all features, so maybe we could defer some actions?)?

[rkeithhill]

I don't see a problem with adding a build for the module particularly if it can halve the module import time. As for as "optional" features, that might be tough as this module doesn't offer that much in the way of optional features. That said, I suppose there might be some folks who want only the tab-completion support. Doubt there are many that want only the prompt status and not tab-completion though.

[dahlbyk]

but one would need to add a build process before publishing the module, one does not need to re-invent the wheel though as one could e.g. use the ModuleBuilder module for that. Would you be happy with that?

We've discussed elsewhere that a pre-publish build process would be useful in other ways, so I'm not opposed to this as a related optimization. I would want to make sure the module can still be loaded as-is from the Git repo, as many folks use their own fork of the project.

As for as "optional" features, that might be tough as this module doesn't offer that much in the way of optional features. That said, I suppose there might be some folks who want only the tab-completion support. Doubt there are many that want only the prompt status and not tab-completion though.

We could conceivably skip loading all the prompt/status infrastructure if $GitPromptSettings.EnablePromptStatus -eq $false, though technically that setting only disables the Git portion of the prompt, not the rest of it (path, etc).

[bergmeister]

Good feedback.
Should I aim to make a PR against the v0 or master branch (or both?). Personally, I still use v0 (accidentally) sometimes because I often forget the -AllowPreRelease switch...

[rkeithhill]

I'd say master as I'd like to nudge folks towards v1. :-)

[bergmeister]

Ok, I've actually opened PRs against both branches. Should we incorporate this into the build as well, by changing the src folder in the test line below to the built module in the out folder?
https://github.com/dahlbyk/posh-git/blob/master/test/Shared.ps1#L1

[rkeithhill]

I'd rather not change that line to always point to the release dir because my typical dev flow is to run Pester tests while I'm doing dev work (not having built). Maybe we can change that line to look for a variable like $PoshModuleToTest. When that variable is not found, we use the current path (to the src dir). The build script could define this variable and set it to the release dir location, and then run the Pester tests.