Suggestion: feature to "rebase" user profiles on top of new defaults.json

[DHowett-MSFT]

0.5 introduced a new base settings file, defaults.json. It's loaded before user settings, and any profiles with matching GUIDs (or GUIDs + sources) have their settings applied on top of any preexisting ones.

A pleasant side effect of that is that anything set in defaults that's set to the same value in the user's settings file can be removed from the user's settings. That'll let Terminal regain control of that setting (for better or for worse.) The user settings emitted by default are a lot smaller thanks to this.

It'd be neat if MSTerminalSettings could look up the location of defaults.json, parse it, and strip out anything from the user settings that matches the default value.

consideration: guid, name, source, hidden

These keys should probably be kept, even if they're the same. name and guid are really helpful for users to identify their profiles (and Terminal uses guid and source as a primary key.)

consideration: globals / root-level settings

We moved to globals because our JSON serializer was being obnoxious and did not allow us to make sure that all global settings were printed at the top of the file. 😄 The new defaults and the new user settings "stub" dispensed with the globals object, but if it's present it'll be preferred over root-level settings.

consideration: dynamic profiles

The preexisting powershell core and WSL profiles have "defaults" that don't exist in any knowable json file; we should totally rectify that. I guess their settings could be stripped out if they matched the cmd profile's settings ... they're close enough.

What do you think?

[DHowett-MSFT]

FWIW: You can find the path to defaults.json fairly easily with Get-AppxPackage. It won't work well for the unpackaged launch scenario, but it's not one we're really officially supporting.

Join-Path ((Get-AppxPackage Microsoft.WindowsTerminal).InstallLocation) "defaults.json"

"C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.5.2661.0_x64__8wekyb3d8bbwe\defaults.json"

[JustinGrote]

I think the best way to do this would be similar to how get-module operates, where by default it only gets the settings explicitly specified in the user profile, whereas adding a "-All" switch to the command would get the full settings including the merged items.

This would be easy to process with Microsoft.Extensions.Configuration but that's a big dependency to take.

Also, the new "well known" dynamic profiles I think should be queryable with a well known parameter flag, e.g. Get-MSTerminalProfile -Dynamic PowerShellCore

I'll look into PRing these changes if I get some time.

[JustinGrote]

@DHowett-MSFT The best option for implementation looks like:

1. Refactor the json parser to return nested hashtables rather than objects (breaking change maybe? Shouldn't be for most cases)
2. Use a merge-hashtable function to generate the "full" config.
3. Return one of the "views" of the 3 files. "user" by default, "full" if -all is specified

Could also try to merge the nested objects but that'd be much uglier than just merging hashtables, I supposed they could be re-output as PSCustomObjects with a recursive function so as not to be a breaking change.