Dartdoc: Add option to generate documentation for private classes

This is as designed. We could add an option to document these, however.

@sathishmscict Are you referring to identifiers that begin with an underscore (_) or identifiers that are not export-ed from the library (i.e. typically used only within /lib/src)?

I'd be interested in it documenting anything in a library that is not explicitly exported as part of its API please!

I'd also be interested in the ability to generate docs for all classes, including private classes.

I have a private class initialized within another class (that is exported/public) to ensure that they cannot initialize it outside of the class and so it doesn't pollute intellisense, but I'd like them to be able to read the documentation on the internal functions for that class.

In Flutter we have stateful widgets, where the public class is normally small and uninteresting, with all the logic in a State class with a private name. These State classes demand documenting!

Any updates on this? Is there any option to document private classes also?

There is no update as yet, but since there's been continuing traffic on this feature request, elevating to P2.

It sounds like the general trend is to desire documentation for all private library members in a library or even package.

If it is going to be at the library or package level I'd perhaps lean toward a dartdoc_options parameter listing files and/or toggling the whole package. Not very fine grained, but either of those two options would get the job done in many cases. Otherwise, a package:meta annotation -- something like @visibleInDocumentation -- would seem to be the way to go, similar to @visibleForTesting. One disadvantage of that approach is that you'd have to tag any non-public symbol with that tag for it to show up. Any thoughts?

@visibleInDocumentation seems the best bet here- as that also gives the option to document certain private members while keeping others completely private.

All of this could be done, where the more specific overrules the more general. In the flutter case, I would like to document my own packages, and not all packages, thus the package level would suit me.

Since annotations can be present on libraries, if we do both probably the dartdoc_options version would be limited to entire packages or directory trees.

This would also be a good time to deprecate the archaic @nodoc dartdoc directive that has to be embedded with documentation comments and replace that with another annotation.

The option to include private classes (_Foo) is important for documenting flutter apps because otherwise, you cannot document StatefulWidgets

yes it would be great if we could document statefulwidgets too. If anyone can point to where private class logging can be enabled, I would like to create a fork and use that meanwhile