-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serialize mdast to markdown #127
base: main
Are you sure you want to change the base?
Conversation
While working on this, I noticed that the JS implementation relies heavily on regular expressions in some places. I believe we can rewrite some parts of the code in Rust instead of depending on the regex crate. Although the regex crate guarantees linear time complexity, we can eliminate the need for the regex engine in places where simpler Rust code would work. Maybe we can benchmark first but this won't happen until I move over most of the tests into Rust. what do you think @wooorm ? One more question what do you think make more sense here for the maintainability of this utility :
|
While the core of As for workspace vs module, I have to particular preference currently. You? |
Since we're working with an AST and this is a utility a workspace sounds better to me this will help to isolate the tests when we quickly run cargo test and version this util by it's own too. It's not that hard to change that decision later on, I updated the PR to use a workspace instead and kept the no_std constrain. |
I'm working on the definition handler and the handler depends on https://github.com/micromark/micromark/tree/main/packages/micromark-util-decode-string to decode a markdown string, I've looked up the code in this crate and found out you've indeed ported some parts of micromark utils. I was wondering if it's ok to make the util from within the markdown crate pub in order to leverage functions such as |
Some of the utils are already pub because they‘re used in https://github.com/wooorm/mdxjs-rs. So, having some utils pub is fine. Also, putting them in separate crates is also fine. |
@wooorm This is ready for review more things might need to be done :
I've made it ready for review to see if you think I've missed something before addressing some of the points above. Thanks ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is such an effort. Thank you! 🙇♂️
I didn’t check line by line, comparing JS to Rust. I’m assuming that you‘ve probably gotten that right, and trust the tests.
Some small nits.
Otherwise, looking forward to the rest of the work.
And, is there anything in particular you want me to look at?
reason: value.to_string(), | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there’s an error struct now in this project, since #114. Which models the JS version vfile-message
. Could that be used here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes sure
|
By looking at the CI it doesn't seem like the tests are running for this project since it's in a separate workspace we probably need to update the CI jobs to include mdast_util_to_markdown in the pipeline. |
fixes #64
TODO handlers :