Haxe documentation generator

To install, run:

haxelib install chxdoc 1.3.0 

See using Haxelib in Haxelib documentation for more information.



This is a Haxe 3 Port of chxdoc, a command line source code documentation system for the Haxe programming language. It is released under a BSD style license.


  • Complete and clean documentation for releases or developer targets
  • Comment tags like @param, @return and @throws
  • Ability to generate docs for private vars, methods, typedefs, classes and enums
  • Templated html file generation


haxelib git chxdoc
haxelib run chxdoc install [optional path]

If the optional path parameter is omitted, chxdoc will be installed to the current directory.

CHXDOC uses a modified version of temploc, the template compiler system by Nicolas Cannasse.

Install the chxdoc.exe file to somewhere on your executable path. The templates directory can be placed anywhere, but chxdoc will read templates out of haxelib if it is installed there.


You may want to start by running chxdoc with the --help switch, which will give you the most up to date switches.

To generate documentation for a haxe project, an xml file for the project must be created. To create one, simply add "-xml myproject.xml" to your haxe command parameters. This will generate the file that chxdoc requires.

The most common usage of chxdoc would be something like:

chxdoc -o docs_dev --developer=true -f myproject.xml
chxdoc -o docs --templatesDir=/chxdoc/templates --template=default -f myproject.xml

Two versions of the documentation would be created, one with all the private data documented (in docs_dev), and a public release of the documentation in docs. All the images and css files from the template will be copied to both directories.

If you are documenting the haxe std library, you need to generate xml files using the "all.hxml" file in the base directory of your installed standard lib. Once the xml files are generated, you could generate flash9, neko and js targets using a command similar to

chxdoc -o docs --tmpDir=_chxdoctmp --templateDir=../chxdoc/templates/default --installTemplate=true --developer=true flash9.xml,flash9,flash neko.xml,neko js.xml,js


Configuration of chxdoc is done using xml files. When run for the first time, chxdoc will create a file .chxdoc in your home directory. This file is always loaded when chxdoc is run. A custom chxdoc config xml file can be created then specified by the --config=mycfg.xml command line switch.

Xml config settings are chained, so multiple --config switches can be specified. The first file loaded is your home .chxdoc file. After that, anything that is specified on the command line overrides current settings, which allows for sourcing multiple xml files and overriding any setting by using command line switches.

The order is

  • Your home .chxdoc file is loaded and parsed
  • Command line arguments from left to right

For example {{{chxdoc -o docs --mergeMeta=true -f flash9.xml --config=project.chxdoc }}} will load the home .chxdoc file, parse it, then set output to docs, then set mergeMeta to true, then load the xml config file project.chxdoc. If that last file sets mergeMeta to false, that will override the settings in project.chxdoc, the command line --mergeMeta, and the default setting in your home .chxdoc.


Most xml configuration items can be specified on the command line using the element name and value. For example {{{}}} is specified as --developer=true on the command line. When using switches on the command line, the equals sign is optional, but is shown here for clarity.


Allow rule for filter chain


Loads a chxdoc configuration file. This option can be specified multiple times,
allowing configuration overlays processed in the order on the command line. See

--createConfig (not available in xml files)

This option writes a default chxdoc config file as chxdocConfig.xml.

--dateLong="%a %b %d %H:%M:%S %Z %Y"

Format for long dates


Format for short dates


Deny rule for filter chain
This tag is a shortcut to setting the following switches:
Since arguments are parsed in order, you could selectively turn off showAuthorTags
in a developer build with:
--developer=true --showAuthorTags=false

-f, --file=name{{{[,platform[,remap]]}}}

Input xml files. _platform_ and _remap_ are optional. If remap is specified, all package
references that match _remap_ are translated to _platform_.


Text that will be added to footer of Type pages


Type pages footer text from file
Generate the todo html file


Text that will be added to header of Type pages


Type pages header text from file

--help (not available in xml)

Command line reference


Extension for generated html files
Install stylesheet from template to output directory
Install images from template to output directory
Install stylesheet and images from template to output directory


Temploc macro file. (default macros.mtt)
Merge metadata tags to doc tags for similar names. If --showMeta is off, this will
have no effect

-o, --output=outputdir

Sets the output directory (defaults to ./docs)
Sets the default policy for the filter chain
Toggles showing @author contents
Toggle showing haxe metadata
Toggle private classes display
Toggle private typedef display
Toggle private enum display
Toggle private method display
Toggle private var display
Toggle showing @todo tags in type documentation


Sets the stylesheet relative to the outputdir


Set the package subtitle


Template name relative to --templatesDir (default is 'default')


Set the base directory for templates. Two special variables are allow in the path.
%HAXELIB% is replaced with the base path of the haxelib repository. %HAXELIBVER% is
replaced with the chxdoc version directory (ie "1,2,0"). A complete path to chxdoc
may look like "%HAXELIB%/chxdoc/%HAXELIBVER%/"


Set the package title


Path for tempory file generation (default ./__chxdoctmp)
Turns on verbose mode


Sets a web password for ?reload and ?showconfig


Parses everything, serializes and outputs .chxdoc.hsd


Set a default path to xml files

Using Tags

Chxdoc adds support for @ tags in your source code comments. To use them, they must be the first non-whitespace character on a line.

 *	This function does very little.
 *	@param a An integer greater than 0
 *	@param s A string
 *	@return True if s is null
 *	@throws When a <= 0
public function myFunc(a : Int, s : String) : Bool 
	if(a <= 0)
		throw new;
	return (s == null);

The current available tags, all of which except for @deprecated can be used multiple times

@return (or @returns)

@author text

Adds an author field

@deprecated Description

Prints a deprecation warning. This tag is not currently in the
provided template, but is parsed.

@param name Description

Adds a notation about a method argument.


Marks a field as private, even if the access is public. This is often used to
hide methods that are internal use only, as Haxe has no 'protected' modifier.

@requires Description

Adds a description for requirements, like a required neko ndll file

@return Description

Adds literal description to html. @returns is also accepted.

@see Description

Adds description as a source to view

@since Date/Revision/Version

A description of when the item was added to the project

@throws full_class_path Description

Will link html documentation to the class path provided, so it
must be a fully qualified class path. (

@todo Description

For generating TODO files and html notes

@type Description

For adding descriptions for anonymous types

@version Description

A version number

Package and Type filtering

Filtering is done with a series of rules that match either package paths or class paths. Each filter has a policy, which is either to "allow" or "deny" building of documentation for the path.

In XML, the configuration looks like

<filters policy="allow">
  <filter policy="deny" path="haxe.rtti.CType"/>
  <filter policy="allow" path="sys.db.Mysql" />
  <filter policy="deny" path="sys.db.*" />

Filters start with a default policy, which is seen in the top {{{}}} element, or specified on the command line by the --policy=allow switch. This is the overall default policy used when a package does not match any filter, so if the class path goes through all the {{{}}} entries without matching, the default policy is applied. When set to allow, by default the documentation will be generated. Conversely if it is set to deny, and does not match any rule, no documentation for it will be created.

To create documentation for only a specific package... say chxdoc itself, it might look like this:

<filters policy="deny">
  <filter policy="allow" path="chxdoc.*" />
  <filter policy="allow" path="/" />

A special path "/" matches any package in the root (like Int or Array), so in addition to allowing classes in the chxdoc namespace, documentation for any root types used will be created.

The filters are applied in the order they appear in the xml configuration, or on the command line. When using the --allow or --deny command line switches, the switch can take a list of values seperated by commas, so the above example could be written on the command line as

chxdoc --allow=chxdoc.*,/

Beware though, the command line args are still parsed left to right, so the first example would have to be written as

chxdoc --deny=haxe.rtti.CType --allow=sys.db.Mysql --deny=sys.db.*


embedded tags like {@link } for things like @see {@link}

If you have any questions, visit #haxe on Freenode (Madrok), or by gmail (damonsbane).

Any suggestions or contributions welcome! A special thanks goes to Franco Ponticelli for the 'default' template.

4 years ago

All libraries are free

Every month, more than thousand developers use haxelib to find, share, and reuse code — and assemble it in powerful new ways. Enjoy Haxe; It is great!

Explore Haxe

Haxe Manual

Haxe Code Cookbook

Haxe API documentation

You can try Haxe in the browser!

Join us on Github!

Haxe is being developed on GitHub. Feel free to contribute or report issues to our projects.

Haxe on Github