[request] `wpjson.settings` callback `fn` required to return passed `theme` instance; missing generated `theme.json` parts otherwise

[strarsis]

[request] `wpjson.settings` callback `fn` required to return passed `theme` instance; missing generated `theme.json` parts otherwise

[kellymears]

I'm willing to hear out arguments for the behavior being different, but this function is working as intended (and as documented).

It gives you the object and asks you to return something:

export interface Mutator {
  (
    json:
      | Partial<Theme.GlobalSettingsAndStyles['settings']>
      | Container<Partial<Theme.GlobalSettingsAndStyles['settings']>>,
  ):
    | Partial<Theme.GlobalSettingsAndStyles['settings']>
    | Container<Partial<Theme.GlobalSettingsAndStyles['settings']>>
}

interface settings {
  (
    input?:
      | Mutator
      | Container<Partial<Theme.GlobalSettingsAndStyles['settings']>>
      | Partial<Theme.GlobalSettingsAndStyles['settings']>
      | boolean,
    raw?: boolean,
  ): this
}

I think it's more confusing for this function to not use what is returned as a value. And it's pretty easy to always return a value with arrow fns and the container interface:

bud.wpjson.settings(theme => theme
  .set('color.custom', false)
  .set('color.customDuotone', false)
)

Regardless, wpjson.settings should arguably be deprecated in #2079 (currently not planning on that). But, I would use bud.wpjson.set over bud.wpjson.settings (PR soon on sage itself):

bud.wpjson
  .set(`settings.color.custom`, false)
  .set(`settings.color.customDuotone`, false)
  .set(`settings.color.customGradient`, false)
  .set(`settings.color.defaultDuotone`, false)

[github-actions]

Message to comment on stale issues. If none provided, will not mark issues stale