-
Notifications
You must be signed in to change notification settings - Fork 352
feat: add Markdown formatter #2148
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
base: main
Are you sure you want to change the base?
Conversation
|
📦 Docs artifacts are ready: https://github.com/elixir-lang/ex_doc/actions/runs/19272855754/artifacts/4534218131 |
|
@josevalim any thoughts here thus far? |
|
Sorry, a bit busy with Elixir v1.19-rc and today I was out of focus. It is in my inbox and I will review it as soon as I can. |
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.
Hey @yordis that's amazing! Let me share some ideas that could be useful.
I was inspecting the generated Markdown files and thinking if we could apply some changes. See the differences here https://gist.github.com/leandrocp/ee4f0ba8325b410b8650ccd26b9b2351 (CompiledWithDocs.md vs CompiledWithDocs_PROPOSAL.md)
- Use frontmatter block to describe global values/notes
- Use the format "Summary / Functions" similar to HTML pages (so Functions become a level 2 heading)
- Include source links
- Reorganize metadata, for eg: add (deprecated) and doc in summary
- Remove links to hexdocs.pm because 1) it breaks the content and I guess that would make it harder for LLMs to parse; 2) I'm not sure it should link to html pages
You can see some examples on https://shopify.dev/docs/api/liquid/basics.md and https://vercel.com/docs/rest-api/reference/sdk.md
e1c6f8f to
a6870e3
Compare
|
@leandrocp thanks for the help, about the formatting, I do not have any strong opinions of the final output, I will leave it to @josevalim and you to decide on that front, I can adjust it |
a6870e3 to
5131f1a
Compare
|
Just a heads up I am on holidays. This is still on top of my list but I cannot promise anything until I am back (next Wednesday). Sorry! |
|
Hey @yordis no strong opinions either, just trying to figure out a format that presents all the info. Regarding links, just to be clear it should contain links eventually but I believe that HexDocs must define how to serve Markdown pages first, for eg something like https://hexdocs.pm/elixir/1.18.4/Enum.md |
|
Some additional context: ExDoc is not tied to HexDocs and vice versa. We should design links with the assumptions it is served by any static host. I am thinking just using Enum.md with an anchor, same as html, is fine though? The anchor won’t actually work, but at least it is some context? |
Yeah it seems appropriate. Shopify docs links to "canonical" URLs, for eg in https://shopify.dev/docs/api/liquid/tags/form you can see a bunch of anchor links, but in the .md docs (https://shopify.dev/docs/api/liquid/tags/form.md) they are rendered as Vercel is not much different, they include relative links inside .md docs, for eg Claude use relative links with anchors, for eg in https://docs.claude.com/en/docs/build-with-claude/prompt-caching you can see a link |
|
I am back. My goal is to release the new hexdocs.pm, review #2055, and then focus on this. |
|
I am around, once you folks aligned, please share a action-driven feedback, I am can put the work on |
5131f1a to
9770ce7
Compare
|
@josevalim could you give a second pass to the code review 🙏🏻 |
|
Hi @yordis, here are a few comments: I generate Elixir docs with this command
when it should be
do
I think you can use the output generated by my previous PR (#1992) It can work as reference (it was a WIP but the main formatting issues where addressed). |
|
@eksperimental should I change the tests to do full equality of the content? Maybe read them from a file snapshot or somthing, I am having a hard time trying to follow the existing tests setup, I can't tell the final structure that easy but I did not want to change it that much neither |
I would focus on the final structure first and then add/update tests accordingly. |
2286b77 to
cbc1367
Compare
|
What should I do about that |
Signed-off-by: Yordis Prieto <[email protected]>
84aca2b to
83c8172
Compare
I think having a subfolder per format would be wise. I think having everything living in the same folder is no longer viable. |
I agree with this! |
- Updated output directory structure for EPUB, HTML, and Markdown formats to use a consistent `.build` subdirectory. - Introduced `output_setup` and `generate_build` functions to manage build file generation and cleanup. - Adjusted file writing logic to ensure proper paths are used for generated files. - Enhanced test cases to reflect changes in the output directory structure.
|
|
I think that's fine. Having it as before epub and html in the main folder and only markdown in it's own sub-folder was not consistent. As more formatters are added, having everything in one folder it will become unmanageable. By having sub-folders give the option to the user to easily create a zip file per formatter for users to download the docs. Maybe having an option to user sub-folders could be desirable to not to break compatibility of apps using this as hexdocs.pm. Those are my 2 cents. |
- Simplified the output directory structure for EPUB, HTML, and Markdown formatters by removing redundant build directory paths. - Updated the `run` function in each formatter to directly use the output path for building. - Enhanced the `update_output_for_formatter` function to streamline output path management in the documentation generation process. - Adjusted related test cases to reflect the new output structure.
The reason I asked is because of hexdocs and how people could "deploy" these artifacts, having the subdir for So, should I duplicate the |
|
Maybe have an optional flag to use sub-folders for now, and not having it the set by default. Later on this can be set by default in v1.0 or remove it completely and make it the default (and only) behavior. Also I think we should ask @josevalim's opinion. |
|
@eksperimental I will wait for @josevalim and hopefully after that we can get a clear path forward, eitherway I can get it done. |
Signed-off-by: Yordis Prieto [email protected]