Moving SMO files to its own dedicated module?

[potatoqualitee]

I am currently working on both making the repository smaller and regularly updating SMO.

I plan to keep more DLLs in the SMO directory instead of cleaning them like I usually do, because cleaning requires manual intervention and I'd like to automate our build process. Keeping the current SMO library structure means that dbatools will be bigger with each download.

I would like to create a new repo called dbatools-library and put our project there, I'd then remove the SMO files from dbatools, and creating a new module with just these giant files. That means that each time you update dbatools, you won't have to update the SMO files unless the SMO files have been updated and dbatools-library's version gets bumped.

Oh and the new repo won't have SMO in it, it'll just have the files needed for the CI/CD build process to do its thing. Also, that CI/CD process will be in my own private repo since I'll be signing it but I'll share the code that's used.

[niphlod]

git-fu aside the only thing that needs to be changed/notified is that downloading the zip from the repo may not suffice to have a fully working module.

[potatoqualitee]

Yep! We will need to get the word out and update a couple scripts. The namely the install.ps1 and Update-Dbatools.

[nvarscar]

I think the repository shouldn't have any binaries whatsoever and all the libraries should be downloaded during the build phase. I know the main concept always was that anyone could download the repo and start using the module, but it may have caught up with us now. I personally consider having binary files in the repository an anti-pattern, especially if the files can be downloaded from an upstream source.
Ideally, of course, all the libraries could be downloaded as dependencies during the module install, but since the Nuget dependencies are not supported, the reasonable way of dealing with it is packaging them with the module. It wouldn't hurt to have a separate module published with those libraries (and maybe some core internal functions?), but in either case, this would break the out-of-the-box one-stop shop git clone functionality. And that's fine, as long as the documentation is updated to use PSGallery or any other artifact storage (such as GH releases, for example).
One other way of dealing with it is using git submodules, but I haven't played with it extensively to understand its worth. But that would definitely help in splitting the binaries out of the repo with minimal changes.

[potatoqualitee]

Agreed! I think this is part of a natural progression. People, including me, have been learning off the repo for 6 years and this is a wonderful step forward 😊