Benjamin Milde

One other example I have would be iso weeks. I'm not sure if they have valid iso strings though, which is why I went for extendable precisions instead of just...

> Module groups have to be declared in mix.exs, which is evaluated before the code is compiled and boundary data is gathered, so I don't think we can do anything...

Before compile does work without problems to add metadata to the current module doc: https://gist.github.com/LostKobrakai/19c326cf1fec6273ee64152bb640d335

In regards to the mix task for module groups: hex does document aliasing as the way to do more than the default `mix docs` (even for using other generators then...

In the docs I'd imagine something like the following: --- ### Boundary This module is part of the boundary `Some.Prefix.*`. The root module for the boundary is: SomeModuleName | "This...

So the documentation metadata I feel good including by default. Unless it's MB of additional filesize, which e.g. for nerves people can be problematic. In such a case I guess...

I feel the other way round is actually better. Always include the metadata (unless there are valid concerns around filesize) and leave the option of enabling/disabling output to the consumer...

I can see your point, but there's not just ex_doc consuming the documentation stored in beam files. Afaik elixir-ls uses data in there, iex's `h module`, …. Those might not...

I created two PRs for the two parts of the issue: #21 #20

The mix task for module groups is now merged. Having additional documentation by `ex_doc` for boundary data seems to be more problematic as expect within boundary itself (if not impossible)...