Feature idea: Allow HJson to specify multiple profiles, and allow user to select a profile at the beginning

[kristovatlas]

This could, for example, spare non-developer users from checks related to dev tools such as homebrew and git. Another example: Lock down browsers less for QA engineers and developers who do not use VMs. H/T @KMHouk

[akerl]

Found this repo, been running through it on my Macs, and had a feature idea that feels like it aligns with this. What I felt would perhaps work for this purpose is to let the user configure on top of the built in checks. Essentially, provide them w/ two paths: source in their own profiles, but also disable/adjust the built in checks. Something like this:

{
    include: [
        "path/to/my/personal/checks.json",
        "path/to/my/companys/checks.json"
    ]
    checks: {
        "IPv6 is disabled on all network interfaces.": disabled
        "Bluetooth is disabled.": required
    }
}

It seems like this would require a couple of frontend mods, and maybe a single backend mod:

• Adjust the CLI arg parsing to support providing the location of a config file like the above
• If the arg is provided, source the stock config, then merge in any provided include files
• Once all configs are loaded, run through checks, altering the confidence level, adding a new confidence level for disabled that causes the check not to fire (useful if a user knows they want to skip a core check but otherwise wants to use the core config)
• Referencing the checks in this profile using the full description field would work, but it's possible it would make sense to provide them w/ shortnames. As an example, rubocop provides each check with a shortname, grouped by category, so for example, the check on line length can be referenced in your config as "Metrics/LineLength".

The last option would be a pretty large undertaking, just due to the volume of checks that would need to have names created. But it also wouldn't need to be a first-pass change, and backwards compat w/ the descriptions would be easy to maintain.

If you like this approach, I'm happy to take a run at implementing it.

[kristovatlas]

Assigning myself the task of thinking over your proposal some more. Thanks for brainstorming, @akerl!

[kristovatlas]

I think I like the shape of it. It would constitute a complex enough change that it would merit the introduction of unit testing to this project, which it needs at some anyway.