search

pngwn / MDsveX

A markdown preprocessor for Svelte.
https://mdsvex.pngwn.io
MIT License
2.36k stars 102 forks source link

MDsveX and MDX current "standardization" ? #43

Closed 0gust1 closed 4 years ago

0gust1 commented 4 years ago

It seems there's an ongoing "standardisation" effort for MDX : https://github.com/mdx-js
https://github.com/mdx-js/specification

But... it seems JSX based.

Reading their transpilation pipeline, it seems that if we can hook into the last steps, it could be usable to generate svelte components. Unfortunately, it also seems that MDX syntax offers less possibilities than the MDsveX one, but I may haven't read enough.

How this project could relate to MDsveX ?

swyxio commented 4 years ago

its basically inspired by MDX but really doesnt have much other relation to it :(

pngwn commented 4 years ago

Yeah, they are similar projects, and MDX was the inspiration, but the practicalities of using MDX directly didn't make sense.

In short, I'd need to overwrite the parser (or parts of it) and the compiler (in its entirety as you can't modify parts of the compiler). mdsvex is a superset of Svelte, so all Svelte syntax is supported in mdsvex files, MDX differs here as it is more limited, as far as I can tell. Originally mdsvex was a restricted subset of Svelte with markdown on top, but that has changed quite significantly over time.

As it happens, when I release the rewrite mdsvex will have a similar pipeline (and uses some of the same tools under the hood: unified, remark, etc.):

mdsvex -> mdast mdast plugins applied mdast -> hast hast plugins applied hast -> svelte

So if the decision were made to follow the MDX spec, or even use the MDX compiler directly, it would be a relatively straightforward switch, but there are currently no plans to do that. I don't see the value presently in tying myself to the decisions made in another project. When things have settled a little and become more stable, it could be considered if the projects are compatible.

0gust1 commented 4 years ago

Thanks a lot for the detailed (and wise) response. It confirms some thoughts I had when reading MDX spec.

We're working on a design-system (containing assets, CSS base and svelte components), and we're on the documentation side at the moment. Tools (storybook) expects that MDX will make their solution fwk independent, but it's not that simple ^^

I don't see the value presently in tying myself to the decisions made in another project.

Yes. Especially when this project is starting to be marketed as "library-independent solution".

Thanks again.

pngwn commented 4 years ago

I'm going to reopen this so I don't forget about it.

After some conversations, it seems there is a push to make MDX integrate with more frameworks so maybe this is something that could happen in the future.

pngwn commented 4 years ago

Having had various conversations about this and had a good chance to reflect on the new MDX spec, even though matching the spec would be easier than ever, I've decided this doesn't make sense for mdsvex. The goal of the mdx project are clearly very different to mine and I don't particularly agree with some of the design decisions for the spec.

As such, I won't be aligning with the mdx spec and this issue can be closed for now. I'll probably revisit this again in the future if anything changes (including my opinion).