Is there a detailed documentation on how to create own jsdoc templates? - jsdoc

Short version:
If I wanted to develop a completely new jsDoc template from scratch, what would I have to read to understand what jsDoc does, what interface my template must provide and what data I get to work with?
Long version:
I've been using jsDoc for a while now and have come across some tags that I would like to add and overview pages that I would like to have generated out of my documentation. Up to now I solved all my "user problems" with usejsdoc.org. I even managed to add a new jsdoc plugin that adds some tags. However, I can't find any developer documentation on how to create templates for jsdoc. I use ink-docstrap so I clicked my way through the template-folder (publish.js, /tmpl, etc.) and somehow got the idea of how everything works. But its very very time consuming.
What should I read to become a jsDoc template pro?

These instructions are the closest I could find:
To create or use your own template:
Create a folder with the same name as your template (for example, mycooltemplate).
Within the template folder, create a file named publish.js. This file must be a CommonJS module that exports a method named publish.
For example:
/** #module publish */
/**
* Generate documentation output.
*
* #param {TAFFY} data - A TaffyDB collection representing
* all the symbols documented in your code.
* #param {object} opts - An object with options information.
*/
exports.publish = function(data, opts) {
// do stuff here to generate your output files
};
To invoke JSDoc 3 with your own template, use the -t command line option, and specify the path to your template folder:
./jsdoc mycode.js -t /path/to/mycooltemplate
Failing that, you can read the source code!

I am running into a similar difficulty with lack of documentation. There is a GitHub issue that has been open for 7 years on this: Provide docs that explain how templates work.
The only example I've found so far of a custom template that doesn't look like just a modified version of the default is Ramda's documentation. It looks like they use a completely custom publish.js script that uses handlebars.js instead of underscore.js templates, constructs a non-hierarchical nav, pulls info from #sig and #category tags, and uses links to github for 'view source' instead of rendering its own html pages for source code.
Some of their code will be difficult to understand unless you are familiar with Ramda and functional programming (they use Ramda itself in their version of publish.js) but dumping out the values of data and docs during execution should help provide insight into what is going on.
It is helpful as well that their template is a single file so you don't have to jump between a lot of partial template files to follow how the doc is constructed.

I've just published my own new jsdoc theme. What I did is I simply copied the default template: https://github.com/jsdoc3/jsdoc/tree/master/templates/default, and worked on that.
I also managed to add grunt with the following features:
* transcompile + minify js files
* parse sass styles and minify them
* refresh the docs when you change something
You can see how it works here: https://github.com/SoftwareBrothers/better-docs

you can customize one of existing templates (default, haruki or silent):
go into node_modules/jsdoc/template and grab on of them into your app directory outside node_modules.
feel free to rename the dir ex: jsdoc-template.
open jsdoc-template update/customize the content as you want. ex: open publish.js find Home and replace My Js App.
update jsdoc.json by adding:
"opts": {
"template": "jsdoc-template"
}
another option to use one of those templates too: jsdoc3 template list examples

Followup to my previous comment about Ramda's JSDoc template. I've since created a customized version of it and published it on GitHub at https://github.com/eluv-io/elv-ramdoc
This is tailored for my company's projects, but it may be helpful as another learning tool. It adds a 'Show private' checkbox, updates Bootstrap to v5.13, replaces Handlebars with Pug, adds JSDoc comments to the publish.js script itself, and supports setting an environment variable to dump data to console during doc generation.

Related

Can you get access to a pages front matter (or other data) in a eleventy (11ty) plugin

I'm creating (would like to create) an eleventy (11ty) plugin that can automatically generate Open Graph images based on a pages data. So in the template:
---
generate_og_image: true
image_text: "text which will be baked into the image"
og_image_filename: some_file_name.jpg
---
#some markdown
...
I can process each file in my .eleventy.js file via plugin using:
module.exports = function (eleventyConfig) {
eleventyConfig.addLinter("og-image-generator", function(content, inputPath, outputPath) {
title = HOW_TO_ACCESS_TEMPLATE_FRONT_MATTER
createImage(title)
});
}
But only have access to the content, inputPath and outputPath of the template.
How can I access the front matter data associated with the Template? Or is there a better way to go about this?
Answering my own question. As #moritzlost mentioned it is not possible directly. I found this workaround.
eleventyComputed allows you to dynamically assign values to keys. It also allows you to call a custom shortcode.
You can pass whatever properties you like from the template into the shortcode. In this case ogImageName the image name, ogImageTemplate a template or background image and text which is the text to be written on that background.
You can even pass in other keys from your front matter and process them as you go.
---
layout: _main.njk
title: "Some title here"
eleventyComputed:
ogImageName: "{% ogCreateImage { ogImageName: title | slug, ogImageTemplate: 'page-blank.png', text: title } %}"
---
Then in .eleventy.js or a plugin:
eleventyConfig.addShortcode("ogCreateImage", function(props) {
const imageName = props.ogImageName
const imageTemplate = props.ogImageTemplate
const imageText = props.text
console.log('-----------------ogCreateImage-----------------');
console.log(`filename: ${imageName}`);
console.log(`using template: ${imageTemplate}`);
console.log(`with the text : ${imageText}`);
// call the image creation code — return filename with extension
const imageNameWithExtension = createOGImage(imageName, imageTemplate, imageText)
return imageNameWithExtension
});
Returning the final filename which you can use in your template.
I've also come across this problem. I don't think what you're trying to do is possible at the moment. There are not many ways for a plugin to hook into the build step directly:
Transforms
Linters
Events
I think events would be the best solution. However, events also don't receive enough information to process a template in a structured way. I've opened an issue regarding this on Github. For your use-case, you'd need to get structured page data in this hook as well. Or eleventy would need to provide a build hook for each page. I suggest opening a new feature-request issue or adding a comment with your use-case to my issue above so those hooks can be implemented.
Other solutions
Another solution that requires a bit more setup for the users of your plugin would be to add your functionality as a filter instead of an automatic script that's applied to every template. This means that the users of your plugin would need to add their own template which passes the relevant data to your filter. Of course this also gives more fine-control to the user, which may be beneficial.
I use a similar approach for my site processwire.dev:
A special template loops over all posts and generates an HTML file which is used as a template for the generated preview images. This template is processed by eleventy. (source)
After the build step: I start a local server in the directory with the generated HTML files, open them using puppeteer and programmatically take a screenshot which is saved alongside the HTML templates. The HTML templates are then deleted.
This is integrated into the build step with a custom script that is executed after the eleventy build.
I've published the script used to take screenshots with Puppeteer as an NPM package (generate-preview-images), though it's very much still in alpha. But you can check the source code on Github to see how it works, maybe it helps with your plugin.

Doxygen : Section id only alphanumerical since 1.8.15-git

I am working on this project : https://sbl.inria.fr/doc, where the documentation is done with doxygen.
We were used to define the id of our sections with the symbol "-" to separate the words, for example :
\section sec-intro Introduction
However, it looks like the convention has changed since doxygen 1.8.15-git and only alpha-numerical characters are accepted, breaking almost all the pages in our documentation.
Unfortunately, we have a large number of pages, and before reviewing the whole documentation, I wanted to know if there is anything that I am missing, like a doxygen option to turn ON / OFF
[edit]
Here is a minimal example that does not work for me, with doxygen 1.8.15-git:
/**
\mainpage My Main Page
Abstract
\section home-intro Introduction
Intro
*/
//! Documented class test
class test{
};
I just create the configuration file and then run doxygen on the directory containing my .hpp file (so that there is no need to specify the path to my header) :
doxygen -g; doxygen
The main page on the output html contains "Abstract", but not the section, and there is a warning in the doxygen log :
test.hpp:6: warning: Invalid section id `home'; ignoring section
[edit 2]
It worked with doxygen 1.8.14. I cloned the project from the git repository, so I had the latest version. Using the tag version for the 1.8.14, it works fine. I changed the title.
I found the cause of the problem, it is a regression on:
Bug 740046 - Negative sign in -Foo::Bar ruins hyperlink in generated output
The github issue causing the problem is https://github.com/doxygen/doxygen/pull/5677 and the pull request https://github.com/doxygen/doxygen/pull/704.
The issue has been fixed in the proposed patch: https://github.com/doxygen/doxygen/pull/6388

How do I set a JSDoc tutorial title?

I'm using JSDoc tutorials, as described in http://usejsdoc.org/about-tutorials.html
I can't get the configuration options to work, and I haven't yet found any examples or discussion of the topic online.
In my trivial example, I pass a tutorials parameter to JSDoc, and it builds a tutorial file for tutorial1.md. I would like to give this tutorial a display name of "First Tutorial".
Following this from the online docs:
Each tutorial file can have additional .js/.json file (with same name, just different extension) which will hold additional tutorial configuration. Two fields are supported:
title overrides display name for tutorial with the one specified in it's value (default title for tutorial is it's filename).
children which holds list of sub-tutorials identifiers.
I tried several attempts at adding tutorial1.json, or tutorial1.js but either JSDoc pukes on the json file, or doesn't seem to recognize anything I throw at it in the js file.
Can anyone suggest a simple format for a tutorial configuration file that should work?
(Edited to include one .js file I tried, which did not change the tutorial display name.)
tutorial1.md
First Tutorial
================
tutorial1.js
/**
#title First Tutorial
*/
#title = "First Tutorial";
title = "First Tutorial";
It works with .json extension but not with a .js extension. jsdoc does not seem to try to even read the file if a .js extension is used. So the doc seems incorrect.
With a .json extension, and using jsdoc 3.2.2, the following works:
{
"title": "Custom Title"
}
Your .json file needs to be in the same directory as your .md file and have the same name (ignoring extensions).

jsdoc tags within html files

after building a web app, I tried out the jsdoc-toolkit. In a config file I added my index.html to the list of source files and also used the x-parameter to make the toolkit aware of the html file.
java -jar jsrun.jar app\run.js -t=templates\jsdoc -x=html,js -c=conf\my.conf
While the doc is generated without any errors, it still ignores any jsdoc annotation I made within the index file.
And when I check the generated doc, the index.html file is listed as source file.
Very simple documentations such as
/**
* testing the doc
* #constructor
*/
function Test(){
}
are simply ignored
Probably because its embedded in tags.
Do you have any idea how to force jsdoc to use this code as well?
Cheers,
zbug

Merging doxygen modules

I have a large amount of code that I'm running doxygen against. To improve performance I'm trying to break it into modules and merge the result into one set of docs. I thought tag files would do the trick, but either I have it configured wrong or I'm misunderstanding how it works.
The directories are laid out:
root +
|-src+
| |-a
|
|-doc+
|-a.dox
|-main.dox
|-main.md
|-output+
|-a+
| |-html
|-main+
|-html
In addition to 'a' there are other peer directories but am starting with one.
a.dox generates output and a tag file into root/doc/output
OUTPUT_DIRECTORY=output/a
GENERATE_TAGFILE = output/a/a.tag
INPUT=../src/a
main.dox just inputs the markdown file that has a mainpage tag and refers to the other projects tag file.
OUTPUT_DIRECTORY=output/main
INPUT = main.md
TAGFILES=output/a/a.tag=output/a/html
Should this merge or link all the docs under main where I can browse 'a' globals, modules, pages, etc? Or does this only generate links to 'a' if I explicitly cross-reference a documented entity in 'a' from inside of 'main'?
If this should work, any thoughts on where my syntax is incorrect? I've tried various ways to define TAGFILES, is the output directory relative to the main.dox file? To the a.tag file? Or to the a/html directory?
If I'm off base an TAGFILES don't work this way, is there another way to merge sets of doxygen directories into one?
Thanks.
I suggest you read this topic on how I recommend to use tag files and the conditions that should apply: https://stackoverflow.com/a/8247993/784672
To answer your first question: doxygen will in general not merge the various index files together (then no performance would be gained). Although for a part you can still get external members in the index by setting ALLEXTERNALS to YES.
Doxygen will (auto)link symbols from other sources imported via a tag file. So in general you should divide your code into more or less self-contained modules/components/libraries, and if one such module depends on another, then import its tag file so that doxygen can link to the other documentation set. If you run doxygen twice (once for the tag file and once for the documentation) you can also resolve cyclic dependencies if you have them.
In my case I made a custom index page with links to all modules, and made a custom entry in the menu of each generated page that linked back to this index (see http://www.doxygen.nl/manual/customize.html#layout) how to add a user defined entry to the navigation menu/tree.