This directory contains documentation for selected parts of SpiderMonkey. The docs are published on the Mozilla Developer Network, but this is the authoritative copy; the MDN pages are updated from these files by a script. At the moment, we have:
js/src/doc/Debugger
, SpiderMonkey's JavaScript debugging API, commonly
known as Debugger
.
js/src/doc/SavedFrame
, SpiderMonkey's compact representation for captured
call stacks.
and that's it.
To format the documentation, you'll need to install Pandoc, a documentation format conversion program. Pandoc can convert Markdown text, which is pleasant to read and write, into HTML, which is what MDN expects.
There are two scripts you may want to use while working with js/src/doc
subdirectories:
format.sh [--mdn] SOURCEDIR OUTPUTDIR
produces HTML from the document
sources in SOURCEDIR, placing the results in OUTPUTDIR. You can then
check their appearance with a web browser.Normally, format.sh arranges the links and HTML metadata so that the
pages view correctly when visited at file://
URLS pointing into
OUTPUTDIR. However, pages published to MDN should not have the HTML
metadata that stand-alone pages need, and their relative positions may be
different; passing the --mdn
switch tells format.sh
to produce output
for publication to MDN, not for previewing on disk.
(Why are the links affected by --mdn
? The MDN wiki allows you to create
a page named .../foo
, and then create sub-pages named .../foo/bar
.
This is a nice way to arrange, say, a summary page and then sub-pages
providing details. But it's impossible to create the parallel structure
on a POSIX file system: .../foo
can't be both a file and a directory,
so the links that would be correct when published on the wiki cannot be
correct when previewing those pages on disk. Since OUTPUTDIR's layout
can't match that of the wiki, we make it match that of SOURCEDIR.)
publish.sh SOURCEDIR OUTPUTDIR KEYID SECRET
calls format.sh
, and then
posts the pages to MDN, using KEYID and SECRET to establish your
identity. This posts only changed pages, so you can run it whenever the
text you have is the right stuff to publish, without creating gratuitous
churn in the MDN page history.To generate KEYID and SECRET, visit the MDN API key generation page.
Storing documentation in the same tree as the sources it describes has several advantages:
It's easy to handle documentation changes as part of the same review process we use for code changes. A patch posted to Bugzilla can contain code, test, and doc changes, all of which can be discussed together.
The version control system that manages the code also manages its documentation. Branching the code (for Nightly, Aurora, Beta, or Release) branches the docs as well, so one can always find the docs that match the code in a given release stage.
Documentation for proposed changes has a natural home: in the patches that implement the change (or, at least, in a patch attached to the bug discussing the change). There's no need to include "(not yet implemented)" markers in the published docs.
Alongside the documentation source files, the SOURCEDIR passed to
format.sh
should contain a file named config.sh
describing the
directory's contents, how to format them, and where they should be
installed. This data is represented as executable shell code; format.sh
and publish.sh
run the subdirectory's config.sh
script to learn what
they should do.
The only effect of running a SOURCEDIR/config.sh
script should be to
invoke the following commands:
base-url BASE
Treat BASE as the common prefix for some URLs appearing as arguments to subsequently executed commands (other than resource files). In describing the other commands, we use the metavariable RELATIVE-URL for URLs that are relative to BASE.
This command should appear before those taking RELATIVE-URL arguments.
BASE is treated as the root directory of the tree of formatted files.
If OUTPUTDIR is the output directory passed to format.sh
or
publish.sh
, then formatted files appear in OUTPUTDIR at the paths
they would appear on MDN relative to BASE.
markdown FILE RELATIVE-URL
label LABEL [FRAGMENT] [TITLE]
Define a label for use in Markdown reference-style links referring to
the file given in the preceding markdown
command. If the second
argument begins with a #
character, it is taken to be an HTML
fragment identifier; the link refers to that fragment in the page.
TITLE, if present, is the title for the link.
For example:
base-url https://devmo/Tools/ markdown Conventions.md Debugger-API/Conventions label conventions "Debugger API: general conventions" label cv #completion-values "Debugger API: completion values"
would mean that Conventions.md
should be processed to create
https://devmo/Tools/Debugger-API/Conventions
; that Markdown files can
refer to that page like this:
... follows some [common conventions][conventions] which ...
and to the #completion-values
fragment in that page like this:
... is passed a [completion value][cv] indicating ...
absolute-label LABEL URL [TITLE]
resource LABEL FILE URL
Treat FILE as a resource file (an image, for example) that should appear at URL. Since MDN likes to place "attachments" like images under different URL prefixes than the wiki pages themselves, URL is not relative to the BASE passed to base-url.
LABEL can be the empty string if no Markdown documents need to refer to this resource file. (For example, the Markdown might use an SVG file, which in turn use the resource file.)
Unfortunately, publish.sh
can't automatically post these resources to
MDN at the moment. However, it will check if the contents have changed,
and print a warning.
Indeed. It should somehow be unified with 'mach doc', which seems to format in-tree docs of a different kind, and use a different markup language (ReStructuredText) and a different formatter (Sphinx).