[lexical-markdown] set shouldMergeAdjacentLines default to be false

[potatowagon]

Description

For backwards compatibility, setting default shouldMergeAdjacentLines = false to not introduce breaking change from the previous npm release.

Github Flavoured Markdown has the same behavior as shouldMergeAdjacentLines = false:

Screen.Recording.2024-09-24.at.2.19.03.PM.mov

Test plan

npm run test-unit
npm run test-e2e-chromium

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 24, 2024 6:37am
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 24, 2024 6:37am

[github-actions]

size-limit report 📦

Path	Size
lexical - cjs	29.85 KB (0%)
lexical - esm	29.66 KB (0%)
@lexical/rich-text - cjs	38.3 KB (0%)
@lexical/rich-text - esm	31.55 KB (0%)
@lexical/plain-text - cjs	36.9 KB (0%)
@lexical/plain-text - esm	28.86 KB (0%)
@lexical/react - cjs	40.04 KB (0%)
@lexical/react - esm	32.91 KB (0%)

[potatowagon]

hi @GermanJablo please set shouldMergeAdjacentLines = true in your implementation to get the behavior in #6629

[GermanJablo]

I wonder if it might be better to use a single prop like "GFM | Commonmark".

Right now, it's just one prop, but in the future, there could be many more for people targeting different specs. I don't think users will want to figure out the right combination of props to match their target spec.

For instance, when using MDX, you typically rely on plugins that handle different converters for each spec.

[potatowagon]

I wonder if it might be better to use a single prop like "GFM | Commonmark".

Right now, it's just one prop, but in the future, there could be many more for people targeting different specs. I don't think users will want to figure out the right combination of props to match their target spec.

For instance, when using MDX, you typically rely on plugins that handle different converters for each spec.

an enum for that would be nice, but likely would have to create a new api for that and mark the old one as deprecated, for backwards compatibilty. perhaps in a future PR. also would have to brainstorm what other flavours and variations there could be and how best to groupd them.

labelling this behavior as GFM would need more research as there could be differences we dont know yet

[etrepum]

LGTM, we should bias towards backwards compatibility here