JavaScript documentation generator for node using markdown and jsdoc

Related tags

Documentation dox
Overview

Dox

Build Status

Dox is a JavaScript documentation generator written with node. Dox no longer generates an opinionated structure or style for your docs, it simply gives you a JSON representation, allowing you to use markdown and JSDoc-style tags.

Installation

Install from npm:

$ npm install -g dox

Usage Examples

dox(1) operates over stdio:

$ dox < utils.js
...JSON...

to inspect the generated data you can use the --debug flag, which is easier to read than the JSON output:

 $ dox --debug < utils.js

utils.js:

/**
 * Escape the given `html`.
 *
 * @example
 *     utils.escape('<script></script>')
 *     // => '&lt;script&gt;&lt;/script&gt;'
 *
 * @param {String} html string to be escaped
 * @return {String} escaped html
 * @api public
 */

exports.escape = function(html){
  return String(html)
    .replace(/&(?!\w+;)/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;');
};

output:

[
  {
    "tags": [
      {
        "type": "example",
        "string": "    utils.escape('<script></script>')\n    // => '&lt;script&gt;&lt;/script&gt;'",
        "html": "<pre><code>utils.escape(&#39;&lt;script&gt;&lt;/script&gt;&#39;)\n// =&gt; &#39;&amp;lt;script&amp;gt;&amp;lt;/script&amp;gt;&#39;\n</code></pre>"
      },
      {
        "type": "param",
        "string": "{String} html string to be escaped",
        "types": [
          "String"
        ],
        "name": "html",
        "description": "string to be escaped"
      },
      {
        "type": "return",
        "string": "{String} escaped html",
        "types": [
          "String"
        ],
        "description": "escaped html"
      },
      {
        "type": "api",
        "string": "public",
        "visibility": "public"
      }
    ],
    "description": {
      "full": "<p>Escape the given <code>html</code>.</p>",
      "summary": "<p>Escape the given <code>html</code>.</p>",
      "body": ""
    },
    "isPrivate": false,
    "ignore": false,
    "code": "exports.escape = function(html){\n  return String(html)\n    .replace(/&(?!\\w+;)/g, '&amp;')\n    .replace(/</g, '&lt;')\n    .replace(/>/g, '&gt;');\n};",
    "ctx": {
      "type": "method",
      "receiver": "exports",
      "name": "escape",
      "string": "exports.escape()"
    }
  }
]

This output can then be passed to a template for rendering. Look below at the "Properties" section for details.

Usage


Usage: dox [options]

  Options:

    -h, --help                     output usage information
    -V, --version                  output the version number
    -r, --raw                      output "raw" comments, leaving the markdown intact
    -a, --api                      output markdown readme documentation
    -s, --skipPrefixes [prefixes]  skip comments prefixed with these prefixes, separated by commas
    -d, --debug                    output parsed comments for debugging
    -S, --skipSingleStar           set to false to ignore `/* ... */` comments

  Examples:

    # stdin
    $ dox > myfile.json

    # operates over stdio
    $ dox < myfile.js > myfile.json

Programmatic Usage

var dox = require('dox'),
    code = "...";

var obj = dox.parseComments(code);

// [{ tags:[ ... ], description, ... }, { ... }, ...]

Properties

A "comment" is comprised of the following detailed properties:

- tags
- description
- isPrivate
- isEvent
- isConstructor
- line
- ignore
- code
- ctx

Description

A dox description is comprised of three parts, the "full" description, the "summary", and the "body". The following example has only a "summary", as it consists of a single paragraph only, therefore the "full" property has only this value as well.

/**
 * Output the given `str` to _stdout_.
 */

exports.write = function(str) {
  process.stdout.write(str);
};

yields:

description:
     { full: '<p>Output the given <code>str</code> to <em>stdout</em>.</p>',
       summary: '<p>Output the given <code>str</code> to <em>stdout</em>.</p>',
       body: '' },

Large descriptions might look something like the following, where the "summary" is still the first paragraph, the remaining description becomes the "body". Keep in mind this is markdown, so you can indent code, use lists, links, etc. Dox also augments markdown, allowing "Some Title:\n" to form a header.

/**
 * Output the given `str` to _stdout_
 * or the stream specified by `options`.
 *
 * Options:
 *
 *   - `stream` defaulting to _stdout_
 *
 * Examples:
 *
 *     mymodule.write('foo')
 *     mymodule.write('foo', { stream: process.stderr })
 *
 */

exports.write = function(str, options) {
  options = options || {};
  (options.stream || process.stdout).write(str);
};

yields:

description:
     { full: '<p>Output the given <code>str</code> to <em>stdout</em><br />or the stream specified by <code>options</code>.</p>\n\n<h2>Options</h2>\n\n<ul>\n<li><code>stream</code> defaulting to <em>stdout</em></li>\n</ul>\n\n<h2>Examples</h2>\n\n<pre><code>mymodule.write(\'foo\')\nmymodule.write(\'foo\', { stream: process.stderr })\n</code></pre>',
       summary: '<p>Output the given <code>str</code> to <em>stdout</em><br />or the stream specified by <code>options</code>.</p>',
       body: '<h2>Options</h2>\n\n<ul>\n<li><code>stream</code> defaulting to <em>stdout</em></li>\n</ul>\n\n<h2>Examples</h2>\n\n<pre><code>mymodule.write(\'foo\')\nmymodule.write(\'foo\', { stream: process.stderr })\n</code></pre>' }

Tags

Dox also supports JSdoc-style tags. Currently only @api is special-cased, providing the comment.isPrivate boolean so you may omit "private" utilities etc.

/**
 * Output the given `str` to _stdout_
 * or the stream specified by `options`.
 *
 * @param {String} str
 * @param {{stream: Writable}} options
 * @return {Object} exports for chaining
 */

exports.write = function(str, options) {
  options = options || {};
  (options.stream || process.stdout).write(str);
  return this;
};

yields:

tags:
   [ { type: 'param',
       string: '{String} str',
       types: [ 'String' ],
       name: 'str',
       description: '' },
     { type: 'param',
       string: '{{stream: Writable}} options',
       types: [ { stream: ['Writable'] } ],
       name: 'options',
       description: '' },
     { type: 'return',
       string: '{Object} exports for chaining',
       types: [ 'Object' ],
       description: 'exports for chaining' },
     { type: 'api',
       visibility: 'public' } ]

Complex jsdoc tags

dox supports all jsdoc type strings specified in the jsdoc documentation. You can specify complex object types including optional flag =, nullable ?, non-nullable ! and variable arguments ....

Additionally you can use typesDescription which contains formatted HTML for displaying complex types.

/**
 * Generates a person information string based on input.
 *
 * @param {string | {name: string, age: number | date}} name Name or person object
 * @param {{separator: string} =} options An options object
 * @return {string} The constructed information string
 */

exports.generatePersonInfo = function(name, options) {
  var str = '';
  var separator = options && options.separator ? options.separator : ' ';

  if(typeof name === 'object') {
    str = [name.name, '(', name.age, ')'].join(separator);
  } else {
    str = name;
  }
};

yields:

tags:
[
  {
    "tags": [
      {
        "type": "param",
        "string": "{string | {name: string, age: number | date}} name Name or person object",
        "name": "name",
        "description": "Name or person object",
        "types": [
          "string",
          {
            "name": [
              "string"
            ],
            "age": [
              "number",
              "date"
            ]
          }
        ],
        "typesDescription": "<code>string</code>|{ name: <code>string</code>, age: <code>number</code>|<code>date</code> }",
        "optional": false,
        "nullable": false,
        "nonNullable": false,
        "variable": false
      },
      {
        "type": "param",
        "string": "{{separator: string} =} options An options object",
        "name": "options",
        "description": "An options object",
        "types": [
          {
            "separator": [
              "string"
            ]
          }
        ],
        "typesDescription": "{ separator: <code>string</code> }|<code>undefined</code>",
        "optional": true,
        "nullable": false,
        "nonNullable": false,
        "variable": false
      },
      {
        "type": "return",
        "string": "{string} The constructed information string",
        "types": [
          "string"
        ],
        "typesDescription": "<code>string</code>",
        "optional": false,
        "nullable": false,
        "nonNullable": false,
        "variable": false,
        "description": "The constructed information string"
      }
    ]

Code

The .code property is the code following the comment block, in our previous examples:

exports.write = function(str, options) {
  options = options || {};
  (options.stream || process.stdout).write(str);
  return this;
};

Ctx

The .ctx object indicates the context of the code block, is it a method, a function, a variable etc. Below are some examples:

exports.write = function(str, options) {
};

yields:

ctx:
 { type: 'method',
   receiver: 'exports',
   name: 'write',
   string: 'exports.write()' } }
var foo = 'bar';

yields:

ctx:
 { type: 'declaration',
   name: 'foo',
   value: '\'bar\'',
   string: 'foo' }
function User() {

}

yields:

ctx:
 { type: 'function',
   name: 'User',
   string: 'User()' } }

Extending Context Matching

Context matching in dox is done by performing pattern matching against the code following a comment block. dox.contextPatternMatchers is an array of all pattern matching functions, which dox will iterate over until one of them returns a result. If none return a result, then the comment block does not receive a ctx value.

This array is exposed to allow for extension of unsupported context patterns by adding more functions. Each function is passed the code following the comment block and (if detected) the parent context if the block.

dox.contextPatternMatchers.push(function (str, parentContext) {
  // return a context object if found
  // return false otherwise
});

Ignore

Comments and their associated bodies of code may be flagged with "!" to be considered worth ignoring, these are typically things like file comments containing copyright etc, however you of course can output them in your templates if you want.

/**
 * Not ignored.
 */

vs

/*!
 * Ignored.
 */

You may use -S, --skipSingleStar or {skipSingleStar: true} to ignore /* ... */ comments.

Running tests

Install dev dependencies and execute make test:

 $ npm install -d
 $ make test

License

(The MIT License)

Copyright (c) 2011 TJ Holowaychuk <[email protected]>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Comments
  • NEEDS example of

    NEEDS example of "opinionated formatting template"...

    See the discussion on this StackOverflow posting: http://stackoverflow.com/questions/6096649/documenting-node-js-projects/6995688#6995688

    Basically, mere mortals are intimidated by the task of creating a template to turn pure "unopinionated" JSON code structure metadata into human consumable "opinionated" HTML. The concept of factoring apart the parser from the formatter is great; we just need an example of how a template would work.... a starting point. Adding this (plus a mention in the README.md) would go a long way towards making this module consumable by others.

    As much as I'd love to do the work myself and submit a "pull request", honestly, I'm not entirely sure how to create such a template either. Not that I'd ever admit that... ;)

    Cheers, --- Dave

    opened by ddopson 32
  • Add `rawString` to markdown-parsed tags

    Add `rawString` to markdown-parsed tags

    I find #139 a fantastic update. But sometimes you just need the raw string.

    For example, we use some tag values as keys when generating a tree representation of our source. For that we need to access the original value of the tags.

    It seems wrong to strip HTML tags from markdown-processed strings just to bring back the original. It's also very fragile.

    enhancement markdown 
    opened by tomek-he-him 22
  • Idea: Support CSS

    Idea: Support CSS

    I know dox isn't designed to document CSS. But in the world of stylesheets there is no tool as flexible, generic, unopinionated and fabulous as dox.

    AFAIK dox only parses comments. CSS comments are compatible with JS comments. Should work out of the box.

    So we already decided to give it a try. Everything worked like a charm. Well, almost everything.

    We've encountered only one pitfall – an escaped apostrophe in a selector (\'). When dox encounters one of these, it truncates all following comments.

    So this works great:

    /**
     * A simple boring class
     */
    .a-simple-boring-class {}
    
    /**
     * Another one
     */
    .another-one {}
    
    $ dox --debug < this
    [ { tags: [],
        description:
         { full: '<p>A simple boring class</p>',
           summary: '<p>A simple boring class</p>',
           body: '' },
        isPrivate: false,
        isConstructor: false,
        isEvent: false,
        ignore: false,
        line: 1,
        codeStart: 4,
        code: '.a-simple-boring-class {}',
        ctx: undefined },
      { tags: [],
        description:
         { full: '<p>Another one</p>',
           summary: '<p>Another one</p>',
           body: '' },
        isPrivate: false,
        isConstructor: false,
        isEvent: false,
        ignore: false,
        line: 6,
        codeStart: 9,
        code: '.another-one {}',
        ctx: undefined } ]
    

    Whereas that fails:

    /**
     * This class's got an apostrophe
     */
    .this-class\'s-got-an-apostrophe {}
    
    /**
     * This will get truncated
     */
    .this-will-get-truncated {}
    
    $ dox --debug < that
    [ { tags: [],
        description:
         { full: '<p>This class&#39;s got an apostrophe</p>',
           summary: '<p>This class&#39;s got an apostrophe</p>',
           body: '' },
        isPrivate: false,
        isConstructor: false,
        isEvent: false,
        ignore: false,
        line: 1,
        codeStart: 4,
        code: '.this-class\\\'s-got-an-apostrophe {}\n\n/**\n * Another one\n */\n.another-one {}',
        ctx: undefined } ]
    

    You can read more about escaped characters in this article by Mathias Bynens.

    bug parsing 
    opened by tomek-he-him 19
  • [feat] Updated jsdoctypeparser package.

    [feat] Updated jsdoctypeparser package.

    This PR is still very much a work in progress.

    1. Added fixture snapshots based on the codebase before the jsdoctypeparser package was updated. I can remove them before taking the PR out of draft mode.
    2. Updated the jsdoctypeparser package and usage.
    3. Removed an unsupported type test. Not sure about this change. I would still like to figure out why this type causes the parser to throw an error (below). I also updated the fixture snapshot to remove this pattern result. Error: SyntaxError: Expected [ \t], [\n], [\r], or end of input but "n" found.
    4. Updated some whitespace in the fixture snapshots.

    The tests currently fail, but I feel like I'm close to fixing the remaining issues.

    > [email protected] test
    > jest test/fixtures.test.js
    
     FAIL  test/fixtures.test.js
      custom parser
        ✓ a (4 ms)
        ✓ alias (1 ms)
        ✓ asterik (12 ms)
        ✓ b (1 ms)
        ✓ c (8 ms)
        ✕ classes (4 ms)
        ✓ d-mixed (1 ms)
        ✓ d-spaces (1 ms)
        ✓ d-tabs (1 ms)
        ✓ d (1 ms)
        ✓ enums
        ✓ event (1 ms)
        ✓ functions (1 ms)
        ✓ issue169
        ✕ jsdoc-complex-types (6 ms)
        ✓ jshint
        ✓ literal-inline (1 ms)
        ✓ multilinetags (2 ms)
        ✓ nodescription (1 ms)
        ✓ prototypes-inline (1 ms)
        ✓ prototypes
        ✓ single-multiline (1 ms)
        ✓ single
        ✓ singleline (1 ms)
        ✓ skip_prefix
        ✓ slash
        ✓ string-quotes (1 ms)
        ✓ throws
        ✓ titles
        ✓ uncommented (1 ms)
    
      ● custom parser › classes
    
        expect(received).toEqual(expected) // deep equality
    
        - Expected  - 1
        + Received  + 1
    
        @@ -84,11 +84,11 @@
                  "type": "return",
                  "string": "{Overflow}",
                  "types": [
                    "Overflow"
                  ],
        -         "typesDescription": "<a href=\"Overflow.html\">Overflow</a>",
        +         "typesDescription": "<code>Overflow</code>",
                  "optional": false,
                  "nullable": false,
                  "nonNullable": false,
                  "variable": false,
                  "description": "",
    
          16 |   }
          17 |
        > 18 |   expect(`${JSON.stringify(results, null, 2)}\n`).toEqual(
             |                                                   ^
          19 |     readFileSync(`./test/fixtures/${filename}.json`, 'utf8')
          20 |   );
          21 | };
    
          at toEqual (test/fixtures.test.js:18:51)
          at Object.testFixture (test/fixtures.test.js:29:35)
    
      ● custom parser › jsdoc-complex-types
    
        expect(received).toEqual(expected) // deep equality
    
        - Expected  - 31
        + Received  + 25
    
        @@ -50,20 +50,18 @@
                  "html": "<p>{number|{name:string,age:number}|Array} a</p>"
                },
                {
                  "type": "returns",
                  "string": "{{name:string,age:number}}",
        -         "types": [
        -           {
        +         "types": {
        -             "name": [
        +           "name": [
        -               "string"
        +             "string"
        -             ],
        +           ],
        -             "age": [
        +           "age": [
        -               "number"
        +             "number"
        -             ]
        +           ]
        -           }
        -         ],
        +         },
                  "typesDescription": "{name: <code>string</code>, age: <code>number</code>}",
                  "optional": false,
                  "nullable": false,
                  "nonNullable": false,
                  "variable": false,
        @@ -102,28 +100,24 @@
                    "string",
                    {
                      "length": [
                        "number"
                      ],
        -             "type": [
        -               {
        +             "type": {
        -                 "name": [
        -                   {
        +               "name": {
        -                     "first": [
        +                 "first": [
        -                       "string"
        +                   "string"
        -                     ],
        +                 ],
        -                     "last": [
        +                 "last": [
        -                       "string"
        +                   "string"
        -                     ]
        +                 ]
        -                   }
        -                 ],
        -                 "id": [
        +               },
        +               "id": [
        -                   "number",
        +                 "number",
        -                   "string"
        +                 "string"
        -                 ]
        +               ]
        -               }
        +             }
        -             ]
                    }
                  ],
                  "typesDescription": "<code>number</code> | <code>string</code> | {length: <code>number</code>, type: {name: {first: <code>string</code>, last: <code>string</code>}, id: <code>number</code> | <code>string</code>}}",
                  "optional": false,
                  "nullable": false,
        @@ -158,11 +152,11 @@
                  "name": "a",
                  "description": "",
                  "types": [
                    "number"
                  ],
        -         "typesDescription": "<code>number</code>|<code>undefined</code>",
        +         "typesDescription": "<code>number</code>=",
                  "optional": true,
                  "nullable": false,
                  "nonNullable": false,
                  "variable": false,
                  "html": "<p>{number=} a</p>"
        @@ -195,11 +189,11 @@
                  "name": "a",
                  "description": "",
                  "types": [
                    "number"
                  ],
        -         "typesDescription": "<code>number</code>|<code>null</code>",
        +         "typesDescription": "?<code>number</code>",
                  "optional": false,
                  "nullable": true,
                  "nonNullable": false,
                  "variable": false,
                  "html": "<p>{?number} a</p>"
        @@ -235,11 +229,11 @@
                    "number"
                  ],
                  "typesDescription": "!<code>number</code>",
                  "optional": false,
                  "nullable": false,
        -         "nonNullable": true,
        +         "nonNullable": false,
                  "variable": false,
                  "html": "<p>{!number} a</p>"
                }
              ],
              "description": {
    
          16 |   }
          17 |
        > 18 |   expect(`${JSON.stringify(results, null, 2)}\n`).toEqual(
             |                                                   ^
          19 |     readFileSync(`./test/fixtures/${filename}.json`, 'utf8')
          20 |   );
          21 | };
    
          at toEqual (test/fixtures.test.js:18:51)
          at Object.testFixture (test/fixtures.test.js:39:11)
    
    Test Suites: 1 failed, 1 total
    Tests:       2 failed, 28 passed, 30 total
    Snapshots:   0 total
    Time:        0.21 s, estimated 1 s
    Ran all test suites matching /test\/fixtures.test.js/i.
    
    opened by neogeek 16
  • Error using v0.1.0

    Error using v0.1.0

    /usr/local/lib/node_modules/dox/lib/dox.js:70 comment.code = code; ^ TypeError: Cannot set property 'code' of undefined at Object.parseComments (/usr/local/lib/node_modules/dox/lib/dox.js:70:18) at [object Object]. (/usr/local/lib/node_modules/dox/bin/dox:40:17) at [object Object].emit (events.js:61:17) at afterRead (fs.js:878:12) at wrapper (fs.js:245:17)

    For every file I try to process.

    opened by aredridel 14
  • fileOverview/file/overview

    fileOverview/file/overview

    Hi dox team,

    Looks like the @file tag is not explicitly supported. This means extras like @requires and @author don't get grabbed other than putting that data into the string/html nodes like so:

        "tags": [
          {
            "type": "file",
            "string": "Uses Gulpjs and gulp-inject to glob files  @author       Scott Nath",
            "html": "<p>Uses Gulpjs and gulp-inject to glob files  @author       Scott Nath</p>"
          }
        ],
    

    Am I correct in this assumption? How difficult would it be to add in functionality for this tag?

    thanks, Scott

    opened by scottnath 12
  • Added better support for jsdoc tags

    Added better support for jsdoc tags

    Hi there

    Great library! This is perfect for use in static site generators where I currently also created a plugin (for assemble.io https://www.npmjs.org/package/assemble-dox )

    I always hoped to use some more complex JSdoc annotations / types tag in dox, so I've created this pull request. Basically it changes the parsing a bit to make it more robust for complex types and white spaces. Then it uses a parser / lexer module to parse the JSDoc tag type strings. As a side effect there is now also support for nullable, non-nullable, vairable and optional on param, return, throws and type tags. Also there is a new typesDescription field on the tag objects that contains an HTML formatted type string.

    I've updated the existing tests slightly (i think there was a wrong handling with the ? sign which is for flagging nullable and not optional) and also added new tests. I've also update the documentation.

    This PR solves #135 and #82.

    Hope I got the whole picture here and didn't miss anything.

    Cheers Gion

    opened by gionkunz 11
  • Support code that is all indented

    Support code that is all indented

    This removes the excess indentation. For example the output in code of the following:

                /**
                 * Test indented function
                 */
                function indented() {
                    foo();
                }
    

    Used to be:

    function indented() {
                    foo();
                }
    

    Which is clearly wrong, with this change, it would be outputted as:

    function indented() {
        foo();
    }
    

    With an extra property of codeIndent which would let you add the spaces back in if you wanted to for some reason (it represents the number of spaces used for the line with the minimum number).

    It leaves tabs in tact and all tests still pass.

    opened by ForbesLindesay 10
  • colons make the line h2

    colons make the line h2

    I see this pull request so I think it's a feature not a bug :p

    But when I parse this comment:

    /**
     * Parse the given comment `str`.
     *
     * The comment object returned contains the following:
     * ...
     */
    

    Then description.body is <h2>The comment object returned contains the following</h2>\n\n<p>...</p> And without the colon after following it's <p>The comment object returned contains the following<br />...</p>

    I think it would be better if it always stays with <p> and if you need <h2> then you can write:

    /**
     * Parse the given comment `str`.
     *
     * ## The comment object returned contains the following:
     * ...
     */
    

    This will always returns <h2>The comment object returned contains the following</h2>\n\n<p>...</p> with or without colons.

    Otherwise if it should stay as it currently is, then there is a small bug because this comment

    /**
     * Parse the given comment `str`.
     *
     *  The comment object returned contains the following
     * ...
     */
    

    will be parsed in <p>The comment object returned contains the following:<br />...</p> even with colon (Notice the two spaces before The comment object...).

    opened by cbou 9
  • Not all comments being parsed.

    Not all comments being parsed.

    parseComments is returning an Array with a length of two for the following file even though it has more than two comments: https://github.com/trusktr/readem/blob/d51f9e899702318526bd7322e10bb1e8fbd671f9/bin/read'em.js

    bug parsing 
    opened by trusktr 8
  • Ignore jshint directives

    Ignore jshint directives

    directives for jshint should be ignored:

      /*jshint latedef:false */
      var define = require('amdefine')(module);
    
    

    results in

    {
        "tags": [],
        "description": {
          "full": "<p>shint latedef:false</p>",
          "summary": "<p>shint latedef:false</p>",
          "body": ""
        },
        "ignore": false,
        "code": "var define = require('amdefine')(module);\n}\n\n\ndefine(function (require) {\n\t'use strict';\n\tvar _ = require('underscore');\n\t\n\tvar type = function(typename,
     required, options) {\n\t\t\tvar t = {type: typename};\n\t\t\tif (required) {\n\t\t\t\tt.required = true;\n\t\t\t}\n\t\t\treturn _.extend(t, options);\n\t};\n\t\n\tvar combine = 
    function(",
        "ctx": {
          "type": "declaration",
          "name": "define",
          "value": "require('amdefine')(module)",
          "string": "define"
        }
      }
    

    Those directives should really be treated as regular code. JSHint does not allow a space between the comment start and jshint or global:

    ok: /*jshint latedef:false */, /*global console:true */ not recognized by jshint: /* jshint onevar:false */

    opened by bernharduw 8
  • Parsing fails with no indication of which file is broken

    Parsing fails with no indication of which file is broken

    I had a function with JSDoc, where I forgot to specify type of object for input parameter, like below /** Some function @param {} timeout */

    While generating a document, parser failed, but it didn't indicate where

    node_modules/jsdoctypeparser/lib/index.js:48 throw new Lexer.SyntaxError(e.message, typeExp, e.offset); ^ TypeLexerSyntaxError: Expected "!", "(", "*", "...", "=", "?", "function", "module", "{" or [a-zA-Z_$] but " " found.:

    opened by dimageller 2
  • Bump verision no

    Bump verision no

    Would it be possible for you to bump the version number? I think the latest commit to bump deps is causing yarn install issues due to yarn not bein able to generate an integrity SHA.

    opened by ChrisCraig68 4
  • Extract parameters from methods, constructors and functions

    Extract parameters from methods, constructors and functions

    This commit adds a property "ctx.params" (an array of strings) to the parsed comment..

    The rationale is that the @param-tags are not necessarily in the same order as the parameters in the code. In the case of

    /**
     * @param {number} a
     * @param {string} b
     */
    function myFunction(b,a) {
    }
    

    it would otherwise not be possible to create the correct documentation (that shows the correct order of the parameter)

    opened by nknapp 1
  • Handling ES-2015 exports

    Handling ES-2015 exports

    I found that dox does a pretty good job on its own for handling ES-2015 and the modules syntax. However when trying to document my API, I found it impossible to tag my re-exported module methods.

    For example:

    /**
     * hrmmm...
     */
    export { html } from './util/tagged-template';
    

    So I came up with this very naive and not at all production ready parser that you can add easily and it might cover your use cases:

    const dox = require('dox');
    
    const parseArgs = str => {
      const arg = /export\s+\{(.*)\}/g.exec(str)[1];
    
      if (arg.indexOf(',') > -1) {
        return arg.split(',').map(str => str.trim()).filter(Boolean)[0];
      }
      else if (arg.indexOf('as') > -1) {
        return arg.split(' as ')[1].trim();
      }
    
      return arg.trim();
    };
    
    // Handle ES6 export syntax.
    dox.contextPatternMatchers.push((string, parentContext) => {
      if (string.indexOf('export') > -1) {
        const name = parseArgs(string);
    
        if (name) {
          return {
            type: 'property',
            name,
            string,
          };
        }
      }
    });
    
    opened by tbranyen 0
  • [improvement] better description handling, and theming idea

    [improvement] better description handling, and theming idea

    A few issues:

    1 Ignore - symbol between type and description

    I have several @param tags. The output in my template is like this:

    screen shot 2016-05-15 at 9 51 25 pm

    The first has no description, the second has only a - for the description, and the third has a fuller description as in - Our UserService injectable.

    It'd be nice if they were more consistent. What I believe is happening (haven't looked at dox code in a while, so just guessing) is that this is a result of the markdown. The first tag has no description, so results in an empty string. The second has only - for the description, so the markdown generates a <p>-</p>, and the last one has a full - description which is treated as a bullet point by markdown, and hence a <ul>.

    JSDoc treats the - between the type and the description as optional, so maybe we should treat it like that too. Idea: the first - that is encountered can be ignored, so if a user really really wants a bullet point, they can write

    @param {Object} foo - - this is a bullet point
    

    Although this makes the comment ugly, it will mean that writing

    @param {Object} foo - this is not a bullet point
    

    is treated as per JSDoc and - is ignored, but also that making a bullet point is more explicit. Suppose we want two paragraphs:

      /*
       * @param {Object} foo - This is paragraph one which is really long and it is
       * split so that it is more readble and so that the line isn't so long.
       *
       * This is paragraph two. This paragraph and the previous are not bullet
       * points.
       */
    

    The result is unexpectedly one bullet and one paragraph:

    screen shot 2016-05-15 at 10 15 34 pm

    but it should just be two paragraphs. Now, if we actually try to make bullet points (with the current non-ignoring of -)

      /*
       * @param {Object} foo - bullet one
       * - bullet two
       */
    

    we get the result

    screen shot 2016-05-15 at 10 28 55 pm

    If we write

    /**
     * @param {Object} foo
     * - bullet one
     * - bullet two
     */
    

    then it works.

    screen shot 2016-05-15 at 10 30 14 pm

    yaaaay! \o/

    2 line breaks

    Seems dox isn't generating line breaks properly? Suppose I have

    /**
     * @param {Object} foo - This is a really long description that I'd like to split into multiple lines so that I can read it better and this line won't be so long.
     */
    

    which is valid JSDoc, now let's split it:

    /**
     * @param {Object} foo - This is a really long description that I'd like to
     * split into multiple lines so that I can read it better and this line won't
     * be so long.
     */
    

    dox (or the markdown) places a <br> right before be so long which results in one long wrapped line and a short line:

    screen shot 2016-05-15 at 10 10 11 pm

    It should instead probably not have any <br> tags, and the whole thing should just wrap. (also note it's a bullet point). So, how can we make it work? Maybe if I put it on a new line:

    /**
     * @param {Object} foo
     * - This is a really long description that I'd like to
     * split into multiple lines so that I can read it better and this line won't
     * be so long.
     */
    

    screen shot 2016-05-15 at 10 33 05 pm

    Aha, so maybe dox is concatenating the @param line with the second line, but this time the first line with @param is empty description-wise, so now it splits on my line breaks.

    Would we have to marked to fix this? Or maybe there's an option? Or maybe we can switch to github-flavored markdown, which already handles paragraphs by combining them together. For example, here on GitHub we can write paragraphs with arbitrary line breaks, and paragraphs are delimited by double line breaks

    this is
    a short
    paragraph
    

    results in:

    this is a short paragraph

    But with dox (marked)

    /**
     * @param {Object} foo
     * this is
     * a short
     * paragraph
     */
    

    screen shot 2016-05-15 at 10 37 12 pm

    TLDR

    We can improve the markdown handling. Perhaps an easy way to do it without swapping the markdown library is to just ignore the first -, then remove single line breaks before passing to marked.

    EDIT: Oh, upon further investigation, looks like marked isn't generating new paragraphs. If I have

    /**
     * @param {Object} foo one paragraph sentence.
     *
     * another paragraph sentence
     */
    

    then I get this markup:

    Uploading Screen Shot 2016-05-15 at 10.43.40 PM.png…

    So, maybe it'd be better to just switch to github flavored markdown, where for

    one paragraph
    with two lines
    
    another paragraph
    with three
    lines.
    

    we get

    screen shot 2016-05-15 at 10 46 29 pm

    screen shot 2016-05-15 at 10 46 00 pm

    opened by trusktr 6
  • Override detected code with jsdoc directives?

    Override detected code with jsdoc directives?

    It's been a while, but I'll be coming back to dox!

    Question: does dox look at the comments when it can't infer from the code? Can we make it prioritize the comments over the code?

    For example, I have

    /**
     * This is the HTML entry point. This is what fires the app running.
     *
     * @class app
     *
     * @example
     * <app />
     */
    angular.module('app').directive('app', function() {
      return {
        template: require('./app.html'),
        restrict: 'E', // custom element only, not attribute directive.
        scope: {}, // use isolate scope for custom elements.
        transclude: false, // if true, means the custom element can have children. Place the children anywhere inside the template using ng-transclude.
        controller: AppCtrl,
        controllerAs: 'app',
        bindToController: true, // always bind to controller with isolate-scope element directives.
      };
    });
    

    Since Angular directives aren't a standard JS thing, I thought I'd just use the @class jsdoc directive to document it (in Angular 2 they are classes anyways). I'm using dox 0.8.1 in dox-foundation, but the class docs don't show up. For example, here's what an actual ES6 class doc looks like in dox-foundation:

    screen shot 2016-05-15 at 7 16 44 pm

    But, here's what happens with the above sample code:

    screen shot 2016-05-15 at 7 17 22 pm

    which leads me to believe that the JSON that dox returns to dox-foundation is different in that case, which is why dox-foundation renders it differently. Is there (maybe we can add) an option to prioritize comments over code?

    opened by trusktr 3
Releases(v1.0.0)
  • v1.0.0(Sep 7, 2022)

  • 0.9.1(Apr 28, 2022)

  • v0.9.0(Aug 13, 2016)

  • v0.8.1(Aug 13, 2016)

  • v0.8.0(Aug 13, 2016)

  • v0.7.1(Apr 3, 2015)

    • Context parsing has been re-factored into an array of functions that are iterated over until a match is found. This array is exposed as dox.contextPatternMatchers, allowing for extension with new contexts without needing to edit the dox source.
    • Fix: ES6 classes extended from sub-properties (such as Backbone.View) are now properly matched
    Source code(tar.gz)
    Source code(zip)
  • v0.7.0(Mar 24, 2015)

    • Add context parsing for some ES6 syntax:
      • classes
      • class constructors
      • class methods
      • assignments via let or const
    • Add support for @description tag
    • Add context match for returned closure
    • Add: Tags without descriptions now have an html property containing a markdown parse of the tag's contents
    • Fix: more agnostic to code style when parsing contexts (eg, no longer ignores functions without spaces between function name and parenthesis)
    • Fix: No longer incorrectly tries to parse strings inside comments, causing large chunks of a file to be ignored.
    • Fix: No longer parses double slash in a string literal as being a comment start.
    • Deps: [email protected]
    Source code(tar.gz)
    Source code(zip)
Owner
TJ Holowaychuk
TJ Holowaychuk
ESDoc - Good Documentation for JavaScript

ESDoc ESDoc is a documentation generator for JavaScript. Please try it out! Features Generates good documentation. Measures documentation coverage. In

ESDoc 2.7k Dec 29, 2022
:book: documentation for modern JavaScript

The documentation system for modern JavaScript ?? Current maintenance status Supports modern JavaScript: ES5, ES2017, JSX, Vue and Flow type annotatio

null 5.6k Jan 4, 2023
YUI Javascript Documentation Tool

YUIDoc YUI's JavaScript Documentation engine. Overview YUIDoc is a Node.js application used at build time to generate API documentation for JavaScript

YUI Library 889 Dec 25, 2022
Pointers to useful, well-written, and otherwise beautiful documentation.

DO YOU WANT TO BUILD AND WRITE GLORIOUS TECHNICAL DOCUMENTATION FULL TIME? EMAIL [email protected]. WE NEED YOU. Beautiful Docs I love documentation. If

Mark Phillips 7.9k Jan 4, 2023
Main repository for the Sphinx documentation builder

Sphinx Sphinx is a tool that makes it easy to create intelligent and beautiful documentation for Python projects (or other documents consisting of mul

null 5.1k Jan 2, 2023
dexy 2.2 1.9 L4 Python is a free-form literate documentation tool for writing any kind of technical document incorporating code.

Dexy Dexy is open source automation software with features especially designed for documentation and reporting. More information at http://dexy.it Doc

null 304 Sep 30, 2022
A collaborative newsroom documentation site, powered by Google Docs.

A collaborative newsroom documentation site, powered by Google Docs.

The New York Times 1k Dec 26, 2022
Adaptation of the popular mkdocs-material material design theme to the sphinx documentation system

Sphinx-Immaterial Theme This theme is an adaptation of the popular mkdocs-material theme for the Sphinx documentation tool. This theme is regularly ma

Jeremy Maitin-Shepard 89 Jan 4, 2023
Simple JavaScript Duckumentation generator.

Warning: JSDuck is no more maintained! If you're looking to adopt a documentation tool, try something else. If you're using JSDuck, consider moving ov

Sencha Labs 1.5k Nov 28, 2022
null 147 Dec 8, 2022
Learn, design or document codebase by putting breadcrumbs in source code. Live updates, multi-language support and more.

What · Demo · Get started · Features · Case studies · Support What Have you ever got lost in a big or unknown codebase? This tool will help you to sol

Bohdan Liashenko 2.6k Jan 3, 2023
Literate Programming can be Quick and Dirty.

____ /\ _`\ \ \ \/\ \ ___ ___ ___ ___ \ \ \ \ \ / __`\ /'___\ /'___\ / __`\ \ \ \_\ \ /\ \ \

Jeremy Ashkenas 3.5k Dec 31, 2022
Tsailun - open source online document and collaboration

Open source selfhosted web-based wiki/doc/knowledge management and collaboration

null 125 Dec 30, 2022
iSphinx 2 Jun 24, 2022
JSDoc generator for JavaScript, TypeScript using AI. (VSCode extension)

JSDoc generator for JavaScript, TypeScript using AI. (VSCode extension)

Amir Reza Dalir 3 Aug 18, 2022
Grupprojekt för kurserna 'Javascript med Ramverk' och 'Agil Utveckling'

JavaScript-med-Ramverk-Laboration-3 Grupprojektet för kurserna Javascript med Ramverk och Agil Utveckling. Utvecklingsguide För information om hur utv

Svante Jonsson IT-Högskolan 3 May 18, 2022
simplified jsdoc 3

jsdox jsdox is a simple jsdoc 3 generator. It pulls documentation tags based on a subset of jsdoc 3 from your javascript files and generates markdown

Sutoiku, Inc. 209 Sep 24, 2022
Hemsida för personer i Sverige som kan och vill erbjuda boende till människor på flykt

Getting Started with Create React App This project was bootstrapped with Create React App. Available Scripts In the project directory, you can run: np

null 4 May 3, 2022
Kurs-repo för kursen Webbserver och Databaser

Webbserver och databaser This repository is meant for CME students to access exercises and codealongs that happen throughout the course. I hope you wi

null 14 Jan 3, 2023
A documentation bot built using slash-create for its documentation, functionality derived from Eris Docs bot.

docs-bot A service that handles navigation of a docgen project manifest. Commands All arguments are required. $ npx slash-up list /docs - Search docu

/create 4 Dec 15, 2022