Allow nested declaration for exposeToBrowser

[pgayvallet]

Summary

Fix #128794

Allow to use a nested structure when defining PluginConfigDescriptor.exposeToBrowser to only expose a subset of a given configuration section/object.

const config = {
  schema: schema.object({
    monitoring: schema.object({
      credentials: schema.string(),
      ccs: schema.object({
        enabled: schema.boolean(),
      }),
      min_interval_seconds: schema.number(),
    })
  }),
  
  exposeToBrowser: {
    monitoring: {
      ccs: {
        enabled: true
      },
      min_interval_seconds: true
    }
  }
};

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[afharo]

LGTM! I just added a few nits for your consideration

[afharo]

Mind the filter in line 225 (I couldn't comment there): since the root values do not necessarily are boolean now, are we OK with validating that a key simply exists?

[pgayvallet]

We're validating that at least one value exists (not a key), but that doesn't change much: Yea, I think we're fine.

Only edge case I see would be a scenario where the descriptor only defines nested keys with false values:

{
   nested: {
      key: false,
   }
}

this would 'bypass' the filtering. But the output of createBrowserConfig would then be an empty object regardless, so I think it's fine.

TBH we could probably get rid of this whole filter block and let createBrowserConfig generates empty configs for all plugins, but I wanted to avoid touching more code than necessary here.

Do you think it would make sense to get rid of this filter block in the current PR?

[afharo]

nit: If we do Array<infer U> instead of any[] we remove the additional any and allow us to support cherry-picking properties in an array of objects if necessary 😇

const config = {
  myArray: [
    {
      propA: 'value',
      propB: 'value',
    }
  ]
};

const exposeToBrowser = {
  myArray: {
    propA: true
  }
}

[pgayvallet]

I 'stupidly' reproduced the type logic of MakeUsageFromSchema from the same file.

If we have a way to get rid of this any, I would be more than happy to. However regarding allowing to pick from the array, I'd rather hold that until we got a specific requirement for it, given the way we would be handling arrays in the exposeToBrowser definition would be slightly different and maybe a bit misleading (objectKey->properties, arrayKey->propertiesOfElements)

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 411efd9
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

Unknown metric groups

API count

id	before	after	diff
core	2375	2376	+1

History

• 💚 Build #34782 succeeded ac1c5b7

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[klacabane]

Added 7.17 and 8.1 labels as Stack Monitoring will need this to fix an issue in previous versions as well :)

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	7.17	Backport failed because of merge conflicts
❌	8.1	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 128864

Questions ?

Please refer to the Backport tool documentation