Basically, in some cases we currently choose for the user that dbatools will behave in a specific manner (e.g. where logs are written).
However, we might be able to actually give them some choice there, by providing a lightweight configuration management system.
The configuration can be made persistent, by storing it in XML (Export-Clixml / Import-Clixml) at the user's discretion (as a parameter on Set-DbaConfig).
Well, in order to really make it useful we'd need to go through all functions, check where configurable settings are hard-coded and update it to use the configuration system. Would probably have to be done in the mob up after the feature freeze (of course, the construct can be finished before that feature freeze).
I've already got a fair portion of one ready to go (just have to remove all the toolkit integrations from it). So yeah, I'd be happy to do it. The question is only: Do we want to do this?
I'm all for it, of course :)
Yes, I'd like that. Where do you propose storing the file? I'm also thinking of a persistent regservers.json file that I'd like to write. Similar to the way dbareports keeps a persistent json file - but this one keeps track of diff servers and their credentials. One of my commands, Invoke-Locate, uses $env:localappdata but maybe that should be appdata or something else entirely.
I'd store things like configurations (and other lightweight stuff of insignificant size) in:
Localappdata is more of a local client only thing and powershell modules can travel along with the users in roaming profiles.