ConsoleGuiTools
ConsoleGuiTools copied to clipboard
PowerShell
Bring package size down
The size of the module is around 290MB's because we ship standalone apps for
win-x64osx-x64linux-x64
This is because of a limitation on non-Windows that forces us to use a separate process to render GUIs.
We can possibly get this down by using AssemblyLoadContext.Default.Resolving and copying duplicate dlls to a shared location. We might be able to do a similar tactic with dlls that ship IN PowerShell itself.
Related: PowerShell PR #9908
How about participating in that PR discussion so that we can have conditional nested modules that are OS-dependent?
In theory, with that PR in place (or something similar) assuming that the PowerShell Gallery did the right thing in such cases (which it should automatically if it's actually loading the manifest hashtable for processing), then the Avalonia bits could be split into three different (nested) modules, and all that would be downloaded from the Gallery would be the modules that are required for the OS where the module is installed. This would also enable other modules that use Avalonia to take the same approach, eliminating unnecessary bulk that could occur across modules if multiple modules require Avalonia.
That would be a much better effort to invest time in because it would solve the broader problem for all modules. Once that is in place, update this module, breaking it out into the main module with three platform-dependent nested modules, and you should be good to go.
This would be the ultimate solve for this issue https://github.com/PowerShell/PowerShellGet/issues/273
I've managed to drop about 50mbs off the package using a custom assembly load event (load xplat dlls from one location rather than 3) and deleting dev dependencies that shouldn't ship with the product.
I think we can do even better with this approach while we wait for a better way offered by PSGet/Gallery
@TylerLeonhardt Which part of PowerShell/PowerShellGet#273 do you think would be the ultimate solve for the issue? The OP recommendation? Or what was suggested at the bottom by Joel?
At the end of the day, PowerShellGet and the PowerShell Gallery are the customers. The scenarios should start there and work their way back to PowerShell. This probably does require a change in PowerShell, but what's needed should ultimately come from a PowerShellGet perspective.
@SteveL-MSFT, https://github.com/PowerShell/GraphicalTools/issues/16#issuecomment-1652634539
No longer relevant
Why?