-
Notifications
You must be signed in to change notification settings - Fork 341
Native support for "umbrella" Erlang projects #2071
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
Comments
We can definitely improve support here and we will consider contributions to reduce the amount of code generation on Erlang itself and other projects. However, I think projects should consider generating a single documentation site, if possible, and use the sidebar groups to organize applications. That's because you will get a better search and autocomplete experience if it is all in a single place. Erlang/OTP itself is too large for this to be a viable option though, so they generate several and use solutions like Algolia for search. I am not sure how feasible Algolia is for private docs. |
You have a fair point about search. I also agree that generating a single site for a project is the ideal solution here, and that's exactly what I'm trying to achieve. I also just realized that One limitation I found while playing with |
@robertoaloi we would definitely accept PRs so you can pass multiple directories 👍 |
It is common for Erlang projects to be composed by several distinct applications. This is usually referred to as an umbrella (or release) project. Since
ex_doc
operates at application level, this means that the user has to figure out a way to produce an index for the project itself.In the case of a
rebar3
project, this is partially solved by the rebar3_ex_doc plugin, which has basic support for umbrella projects. For Erlang projects not using rebar3, this has to be solved case by case.The most notorious example is Erlang/OTP itself, where an index of all modules is generated here, and a fake index application is defined and used to get the feeling of a single projects. This approach requires custom, duplicated logic for various projects.
Was it ever considered to add native support for umbrella projects to
ex_doc
itself? I believe it would simplify its usage outside of rebar3 and increase its adoption.The text was updated successfully, but these errors were encountered: