There are also multiple occurrences of the direct usages of the eui markdown component too across the codebase, all of this unfortunately leads to a lack of coherence with the markdown style across the app especially that the eui markdown component, being built on top of remark (basically a text processor) allows any direct usage of the EUI markdown component the addition of any plugin of choice which could in turn further diversify the markdown styles Kibana supports.
This became very evident, with the attempt to migrate parts of the codebase to the shared UX component, we had reports of in consistencies in rendering expectations. See https://github.com/elastic/kibana/issues/180576
Proposal;
Decide on the markdown flavour Kibana is choosing to support, and exclusively support only this flavour.
On deciding what the flavour to adopt commonmark or GfM, the shared UX team will provide a component that supports this decided on implementation provided for adoption, with tests put in place to validate how markdown renders happen so that any future change to this is caught something along the lines of https://github.com/elastic/kibana/pull/180926 should be sufficient.
All parts of kibana will be migrated to the aforementioned component, guard rails should also be put in place to enforce that only this implementation is what is used across the app.
Describe the feature:
At the moment, within Kibana there exists multiple markdown implementations across the app; we have the legacy markdown component that leverages the package markdown-it which adheres to the commonmark spec then there's the markdown component provided by the shared UX team which is built on top of the Markdown component provided by EUI team which aims to adhere to the Github flavor markdown spec (referred to from here on as GfM), see https://github.com/elastic/eui/pull/5272#pullrequestreview-784790063.
There are also multiple occurrences of the direct usages of the eui markdown component too across the codebase, all of this unfortunately leads to a lack of coherence with the markdown style across the app especially that the eui markdown component, being built on top of remark (basically a text processor) allows any direct usage of the EUI markdown component the addition of any plugin of choice which could in turn further diversify the markdown styles Kibana supports.
This became very evident, with the attempt to migrate parts of the codebase to the shared UX component, we had reports of in consistencies in rendering expectations. See https://github.com/elastic/kibana/issues/180576
Proposal;