[EuiMarkdownFormat/Editor] Allow configuring default plugins

[hsk11]

Summary

closes #7919

This PR adds the ability to configure EUI's default parsing and processing plugins (on a limited basis for processing). Example usage:

const { parsingPlugins, processingPlugins } = getDefaultEuiMarkdownPlugins({
  // Exclude plugins as necessary
  exclude: ['emoji'],
  parsingConfig: {
    // Customize what link protocols are allowed
    linkValidator: { allowProtocols: ['https:', 'mailto:'] },
  },
  processingConfig: {
    // Configure all links to open in new tabs/windows
    linkProps: { target: '_blank' },
  },
});

// Pass the customized plugins to your markdown component
<EuiMarkdownFormat
  parsingPluginList={parsingPlugins}
  processingPluginList={processingPlugins}
/>

QA

Note that a majority of config regression QA testing should be handled by the new markdown_format.test.tsx file.

• https://eui.elastic.co/pr_7985/#/editors-syntax/markdown-plugins#configuring-the-default-plugins
• exclude config should work as before

General checklist

• Browser QA
  • Checked in Chrome, Safari, Edge, and Firefox
    - [ ] Checked in both light and dark modes
    - [ ] Checked in mobile
    - [ ] Checked for accessibility including keyboard-only and screenreader modes
• Docs site QA
  • Updated documentation
  • Props have proper autodocs (using @default if default values are missing) and playground toggles
    - [ ] Checked Code Sandbox works for any docs examples
• Code quality checklist
  • Added jest and cypress tests
    - [ ] Updated visual regression tests
• Release checklist
  • A changelog entry exists and is marked appropriately.
    - [ ] If applicable, added the breaking change issue label (and filled out the breaking change checklist)
• Designer checklist - N/A

[cla-checker-service]

💚 CLA has been signed

[cee-chen]

@hsk11, I took over and extended your PR to apply to the generic getDefaultEuiMarkdownPlugins() function, as that is generally the API in which we want consumers to interact with our markdown plugins, rather than the components directly (which should have higher component-level concerns instead). This also enables EuiMarkdownEditor to benefit from this configuration and not just EuiMarkdownFormat (since they both accept the same plugins props).

The following setup will result in the outcome #7919 asks for:

const { processingPlugins } = getDefaultEuiMarkdownPlugins({
  processingConfig: {
    linkProps: { target: '_blank' },
  },
});

<EuiMarkdownFormat processingPluginList={processingPlugins}>
  [Opens in new tab](https://elastic.co)
</EuiMarkdownFormat>

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 186393f

History

• 💔 Build #2648 failed 39774fc
• 💔 Build #2644 failed 170eda6

[hsk11]

@hsk11, I took over and extended your PR to apply to the generic getDefaultEuiMarkdownPlugins() function, as that is generally the API in which we want consumers to interact with our markdown plugins, rather than the components directly (which should have higher component-level concerns instead). This also enables EuiMarkdownEditor to benefit from this configuration and not just EuiMarkdownFormat (since they both accept the same plugins props).

The following setup will result in the outcome #7919 asks for:

const { processingPlugins } = getDefaultEuiMarkdownPlugins({
  processingConfig: {
    linkProps: { target: '_blank' },
  },
});

<EuiMarkdownFormat processingPluginList={processingPlugins}>
  [Opens in new tab](https://elastic.co)
</EuiMarkdownFormat>

Thanks, Even I thought of Directly Editing there But did not changed it Because Wanted to make Sure i wont Break the getDefaultEuiMarkdownPlugins(), as some people might be using it the way you implemented it now. IMO it would be great if we also just allow to set linkTraget just by passing the prop in EuiMarkDownFormat component .