Granularity of Packages

[michael-hawker]

Especially for UWP, many XAML controls means an increase to the size of your application footprint, even if they're unused.

(I'm not sure if the same applies to WinUI 3, but I believe it does as well? If anyone knows for sure, let us know!)

To that effect in WCT 7.0 we split apart packages into smaller bunches.

Now with vNext, we can ship individual components more easily while making them easier to work on and maintain as well.

What are folks thoughts on this on balancing individual packages vs. similar groups vs. everything?

[Pdawg-bytes]

I think similar groups is the best approach. It's right in the middle of the two and while using less space, it makes it easier to use more components and APIs at once instead of adding a ton of usings for all the different sub packages.

[huynhsontung]

+1

Unless there is a massive size difference to the final binary with all the new components, it's not something I worry about. I think the current grouping makes sense and strikes a good balance of granularity.

[michael-hawker]

Yeah, we want to do a better job of analyzing package size footprint/impact in our CI.

The problem even with the more granular groups is that overtime they require more dependencies (even if the majority of components don't require them) or it creeps up on needing to be split up again to maintain that boundary. So, then you need a new grouping and folks need to know what that is and where they went.

I think each control at minimum adds roughly 100kb of overhead, if I remember correctly? So, like after 8-10 controls you're getting a sizable impact if your app is just using a single one.

[bogdan-patraucean]

Maybe offer both options so folks can choose. (everything + individual packages). Similar groups might create confusion as you don't exactly know what package will include what control without research.

On the other hand I feel like individual packages will require much more effort for mentaining so considering this, and the fact that the actual size is not much of a problem this days (cost of storage, capacity, bandwith) I'll be more than fine with one package for everything.

Ideally I think individual + everything would offer best of both worlds. Those who care about the size will make the extra effort of including everything manually, otherwise, if that's not a problem, a package with everything is perfect.

[michael-hawker]

Yeah, in the current setup we have a 'meta' package which just includes the other packages so you can get everything easily.

We designed our new infrastructure to just ship individual packages, so there's not much overhead in having many of them outside of organization as we can't have nested folders in the components folder currently (but that could be solvable).

I think there's extra overhead in multiple dlls, so we could investigate if we could compile/bundles things together more effectively for sub-packages or something. Or maybe optimizations in the platform make teasing out what's not used more efficient. That's another avenue longer in the future (related to my comment about UWP here).

[KWodarczyk]

I think that there should be option for an end user to choose either individual packages or everything in one package. Some companies do not like if there is a lot of nuggets included in their solution and it's easier to convinced them it use one nugget that is bigger than 10 that are smaller. Also form legal perspective the client of the nuget needs to list all the 3rd party software and the license so it's easier to just have one. So I think it could be nice if there was an option. Not user if there should be anything in between like medium packages that include smaller ones etc. as this will just be confusing and will do more bad than good. MSFT stack and technologies are confusing enough and is very hard anyone coming to .net to fined what they need i would advise to not make same mistake.

[michael-hawker]

Last call for any additional feedback on this topic. In general, it seems smaller packages is the way forward. Though we should still make a meta-package, filed #115 for tracking this.

Should probably investigate a bit the impact of how this effects binary size though of an app...

[KWodarczyk]

definitely there should be option to get individual packages the main benefit of that is that if it was all i one package and there was security issue in WCT every consumer of this one package would be affected, if it's broken down to small packaged then there might security issue on one of them but now all so the number of affected consumer would be much smaller. But there should also be an option to get the whole thing in one go for those who use WCT extensively.