I am working on an app wich will become quite huge in time. I have decided to use JsDoc3
and DocStrap
to document all modules. Modules are defined via require.js and in some places they are nested up to 3 or 4 levels deep.
Untill now I understand that JsDoc documentation is split into four main sections: Modules, Classes, Tutorials, Globals. Each section has a header dropdown menu and a sidebar each of them listing all of the modules in liniar fashion, alphabetically.
I was wondering if there are options to display/group modules and Classes somehow to reflect the project structure. I saw a git repository that document all the classes with lots of slashes module1/submodule1/class1
, but it feels really though to diggest this type of navigation. Not to mention that the layout was having trouble with long titles overflowing from the sidebar.
Currently I have a project layout similar to the schema from bellow. It's wide and deep and I expect it to grow further.
/Editor
---/Services
------/UI
------...
---...
---editorApp.js
/Engine
---/Core
------/...
---/Entities
------/...
---/Graphics
------/...
---/...
...
engine.js
/Web
---/Services
------/UI
------...
---...
---webApp.js
I've just published a new version of better-docs template which supports
@category
tag. Long story short you can add@category
tag to your class/module/whatever and it will be namespaced in the sidebar.Excellent question. I’ve run into the same problem too.
I use namespaces to group classes together into a single package. A big project could have multiple namespaces. A really big project could have namespaces whose members are themselves namespaces.
A namespace is basically a grouping of static objects. You can use
@namespace
to document an object literal, or a “static class” that shouldn’t be constructed, for example, the nativeMath
class.Unfortunately there is no easy way to label modules as members of namespaces, so I’ve abandoned the
@module
tag altogether, using only@class
and@namespace
. Another really annoying thing about modules is you have to prependmodule:
in front of every mention of a module in JSDoc comments. E.g. you must do@type {module:my_mod}
instead of just@type {my_mod}
.So the structure of your project would look like this:
Editor.js
Services.js
UI.js (let’s say UI is a class)