パッケージの詳細

dgeni

angular49.9kMIT0.4.14

Flexible JavaScript documentation generator used by both AngularJS and Angular

readme

Dgeni - Documentation Generator Build Status

The node.js documentation generation utility by angular.js and other projects.

Dgeni is pronounced like the girl name Jenny (/ˈdʒɛni/), i.e the d is silent and the g is soft.

Getting started

Try out the Dgeni example project. Or maybe you're looking for an example using AngularJS.

Watch Pete's ng-europe talk on Dgeni :

ScreenShot

Documenting AngularJS Apps

There are two projects out there that build upon dgeni to help create documentation for AngularJS apps:

Do check them out and thanks to Ilya and Bound State Software for putting these projects together.

Installation

You'll need node.js and a bunch of npm modules installed to use Dgeni. Get node.js from here: http://nodejs.org/.

In the project you want to document you install Dgeni by running:

npm install dgeni --save-dev

This will install Dgeni and any modules that Dgeni depends upon.

Running Dgeni

Dgeni on its own doesn't do much. You must configure it with Packages that contain Services and Processors. It is the Processors that actually convert your source files to documentation files.

To run the processors we create a new instance of Dgeni, providing to it an array of Packages to load. Then simply call the generate() method on this instance. The generate() method runs the processors asynchronously and returns a Promise that gets fulfilled with the generated documents.

var Dgeni = require('dgeni');

var packages = [require('./myPackage')];

var dgeni = new Dgeni(packages);

dgeni.generate().then(function(docs) {
  console.log(docs.length, 'docs generated');
});

Running from the Command Line

Dgeni is normally used from a build tool such as Gulp or Grunt but it does also come with a command line tool.

If you install Dgeni globally then you can run it from anywhere:

npm install -g dgeni
dgeni some/package.js

If Dgeni is only installed locally then you either have to specify the path explicitly:

npm install dgeni
node_modules/.bin/dgeni some/package.js

or you can run the tool in an npm script:

{
  ...
  scripts: {
    docs: 'dgeni some/package.js'
  }
  ...
}

The usage is:

dgeni path/to/mainPackage [path/to/other/packages ...] [--log level]

You must provide the path to one or more Dgeni Packages to load. You can, optionally, set the logging level.

Packages

Services, Processors, configuration values and templates are be bundled into a Package. Packages can depend upon other Packages. In this way you can build up your custom configuration on top of an existing configuration.

Defining a Package

Dgeni provides a Package constructor to create new Packages. A Package instance has methods to register Services and Processors, and to configure the properties of Processors:

var Package = require('dgeni').Package;
var myPackage = new Package('myPackage', ['packageDepencency1', 'packageDependency2']);

myPackage.processor(require('./processors/processor1'));
myPackage.processor(require('./processors/processor2'));

myPackage.factory(require('./services/service1'));
myPackage.factory(require('./services/service2'));

myPackage.config(function(processor1, service2) {
  service2.someProperty = 'some value';
  processor1.specialService = service2;
});

Services

Dgeni makes significant use of Dependency Injection (DI) to instantiate objects. Objects that will be instantiated by the DI system must be provided by a factory function, which is registered in a Package, either as a Processor, by myPackage.processor(factoryFn), or as a Service, by myPackage.factory(factoryFn).

Defining a Service

The parameters to a factory function are dependencies on other services that the DI system must find or instantiate and provide to the factory function.

car.js:

module.exports = function car(engine, wheels) {
  return {
    drive: function() {
      engine.start();
      wheels.turn();
    }
  };
};

Here we have defined a car service, which depends upon two other services, engine and wheels defined elsewhere. Note that this car service doesn't care how and where these dependencies are defined. It relies on the DI system to provide them when needed.

The car service returned by the factory function is an object containing one method, drive(), which in turn calls methods on engine and wheels.

Registering a Service

You then register the Service with a Package:

myPackage.js:

var Package = require('dgeni').Package;

module.exports = new Package('myPackage')
  .factory(require('./car'));

This car Service is then available to any other Service, Processor or configuration block:

var Package = require('dgeni').Package;

module.exports = new Package('greenTaxiPackage', ['myPackage'])

  .factory(function taxi(car) {
    return {
      orderTaxi: function(place) { car.driveTo(place); }
    };
  })

  .config(function(car) {
    car.fuel = 'hybrid';
  });

Processors

Processors are Services that contain a $process(docs) method. The processors are run one after another in a pipeline. Each Processor takes the collection documents from the previous Processor and manipulates it, maybe inserting new documents or adding meta data to documents that are there already.

Processors can expose properties that tell Dgeni where in the pipeline they should be run and how to validate the configuration of the Processor.

  • $enabled - if set to false then this Processor will not be included in the pipeline
  • $runAfter - an array of strings, where each string is the name of a Processor that must appear earlier in the pipeline than this Processor
  • $runBefore - an array of strings, where each string is the name of a Processor that must appear later in the pipeline than this one
  • $validate - a http://validatejs.org/ constraint object that Dgeni uses to validate the properties of this Processor.

Note that the validation feature has been moved to its own Dgeni Package processorValidation. Currently dgeni automatically adds this new package to a new instance of dgeni so that is still available for backward compatibility. In a future release this package will be moved to dgeni-packages.

Defining a Processor

You define Processors just like you would a Service:

myDocProcessor.js:

module.exports = function myDocProcessor(dependency1, dependency2) {
  return {
    $process: function (docs) {
        //... do stuff with the docs ...
    },
    $runAfter: ['otherProcessor1'],
    $runBefore: ['otherProcessor2', 'otherProcessor3'],
    $validate: {
      myProperty: { presence: true }
    },
    myProperty: 'some config value'
  };
};

Registering a Processor

You then register the Processor with a Package: myPackage.js:

var Package = require('dgeni').Package;

module.exports = new Package('myPackage')
  .processor(require('./myDocProcessor'));

Asynchronous Processing

The $process(docs) method can be synchronous or asynchronous:

  • If synchronous then it should return undefined or a new array of documents. If it returns a new array of docs then this array will replace the previous docs array.
  • If asynchronous then it must return a Promise, which should resolve to undefined or a new collection of documents. By returning a Promise, the processor tells Dgeni that it is asynchronous and Dgeni will wait for the promise to resolve before calling the next processor.

Here is an example of an asynchronous Processor

var qfs = require('q-io/fs');
module.exports = function readFileProcessor() {
  return {
    filePath: 'some/file.js',
    $process(docs) {
      return qfs.readFile(this.filePath).then(function(response) {
        docs.push(response.data);
      });
    }
  };

Standard Dgeni Packages

The dgeni-packages repository contains many Processors - from basic essentials to complex, angular.js specific. These processors are grouped into Packages:

  • base - contains the basic file reading and writing Processors as well as an abstract rendering Processor.

  • jsdoc - depends upon base and adds Processors and Services to support parsing and extracting jsdoc style tags from comments in code.

  • typescript - depends upon base and adds Processors and Services to support parsing and extracting jsdoc style tags from comments in TypeScript (*.ts) code.

  • nunjucks - provides a nunjucks based rendering engine.

  • ngdoc - depends upon jsdoc and nunjucks and adds additional processing for the AngularJS extensions to jsdoc.

  • examples - depends upon jsdoc and provides Processors for extracting examples from jsdoc comments and converting them to files that can be run.

  • dgeni - support for documenting dgeni Packages.

Pseudo Marker Processors

You can define processors that don't do anything but act as markers for stages of the processing. You can use these markers in $runBefore and $runAfter properties to ensure that your Processor is run at the right time.

The Packages in dgeni-packages define some of these marker processors. Here is a list of these in the order that Dgeni will add them to the processing pipeline:

  • reading-files (defined in base)
  • files-read (defined in base)
  • parsing-tags (defined in jsdoc)
  • tags-parsed (defined in jsdoc)
  • extracting-tags (defined in jsdoc)
  • tags-extracted (defined in jsdoc)
  • processing-docs (defined in base)
  • docs-processed (defined in base)
  • adding-extra-docs (defined in base)
  • extra-docs-added (defined in base)
  • computing-ids (defined in base)
  • ids-computed (defined in base)
  • computing-paths (defined in base)
  • paths-computed (defined in base)
  • rendering-docs (defined in base)
  • docs-rendered (defined in base)
  • writing-files (defined in base)
  • files-written (defined in base)

Configuration Blocks

You can configure the Services and Processors defined in a Package or its dependencies by registering Configuration Blocks with the Package. These are functions that can be injected with Services and Processors by the DI system, giving you the opportunity to set properties on them.

Registering a Configuration Block

You register a Configuration Block by calling config(configFn) on a Package.

myPackage.config(function(readFilesProcessor) {
  readFilesProcessor.sourceFiles = ['src/**/*.js'];
});

Dgeni Events

In Dgeni you can trigger and handle events to allow packages to take part in the processing lifecycle of the documentation generation.

Triggering Events

You trigger an event simply by calling triggerEvent(eventName, ...) on a Dgeni instance.

The eventName is a string that identifies the event to be triggered, which is used to wire up event handlers. Additional arguments are passed through to the handlers.

Each handler that is registered for the event is called in series. The return value from the call is a promise to the event being handled. This allows event handlers to be async. If any handler returns a rejected promise the event triggering is cancelled and the rejected promise is returned.

For example:

var eventPromise = dgeni.triggerEvent('someEventName', someArg, otherArg);

Handling Events

You register an event handler in a Package, by calling handleEvent(eventName, handlerFactory) on the package instance. The handlerFactory will be used by the DI system to get the handler, which allows you to inject services to be available to the handler.

The handler factory should return the handler function. This function will receive all the arguments passed to the triggerHandler method. As a minimum this will include the eventName.

For example:

myPackage.eventHandler('generationStart', function validateProcessors(log, dgeni) {
  return function validateProcessorsImpl(eventName) {
    ...
  };
});

Built-in Events

Dgeni itself triggers the following events during documentation generation:

  • generationStart: triggered after the injector has been configured and before the processors begin their work.
  • generationEnd: triggered after the processors have all completed their work successfully.
  • processorStart: triggered just before the call to $process, for each processor.
  • processorEnd: triggered just after $process has completed successfully, for each processor.

License

Apache 2

更新履歴

ChangeLog

0.4.14 5 March 2021

Chore release - updating dependencies

0.4.13 11 January 2021

fix(Dgeni): do not print stack trace on error unless debugging (a3c870d)

0.4.12 14 March 2019

Chore release - updating dependencies

0.4.11 17 December 2018

Chore release - updating TypeScript dependency

0.4.10 14 August 2018

Chore release - updating dependencies

0.4.9 15 June 2017

Chore release

0.4.8 15 June 2017

  • fix(processor): add missing fields to Processor type definition b4ed72f0

0.4.7 15 February 2017

  • fix(mocks): ensure mock logger is available in the published package ca43a807

v0.4.6 (14th February 2017)

  • fix(Dgeni): ensure that the typings are exposed correctly a0fc03c9

v0.4.5 (14th February 2017)

False start!

v0.4.4 (13th February 2017)

Minor docs and chores updates; in particular the @types/mocha dependency was moved to devDependencies to prevent unwanted leakage into client projects.

v0.4.3 (12th February 2017)

Various docs and refactorings including a complete rewrite in typescript, which enables API typings for TypeScript users.

v0.4.2 (6th January 2016)

Node dependency update - dgeni now cleanly support node 4 and 5 (and so npm 3)

v0.4.1 (4th October 2014)

Minor Bug Fix

  • fix(Package): allow use of npm link with dgeni 6698fe9f

v0.4.0 (10th September 2014)

Major New Release

This is a major re-architecting from v0.3.0 of how Dgeni uses Dependency Injection and configuration.

This version of Dgeni is compatible with dgeni-packages v0.10.0

  • Dgeni is now configured by Packages, which can depend on other Packages. You create an instance of Dgeni, passing in the Packages that are to be loaded.

  • Packages contain Services, Processors and Config Blocks, which are all instantiated or invoked by the DI system.

  • Dgeni specific properties on Processors are now prefixed with a $. E.g. $process(), $runBefore, $runAfter.

  • Processors themselves are special instances of DI Services. In the previous versions of dgeni the process() method was being invoked by the DI system instead. Now since the processor itself is created by a factory function that can be injected with Services, much more can be done to configure the Processor before the $process(docs) method is called.

  • Processors can now be "validated" using validatejs.org constraints, specified in the processor.$validate property.

  • Processors can now be disabled by setting processor.$enabled = false.

  • Services and Processors with the same name will override previously registered ones, say from a Package dependency. This enables custom Packages to provide alternate components and makes mocking much easier in tests.

  • New injectable helper services have been provided: dgeni, log, getInjectables.

  • Each instance of Dgeni now exposes a configureInjector() method, which returns the configured dgeni DI injector. This is useful in unit testing to easily get access to the Services and Processors to be tested.

  • Now use the injectable log service in your Processors and Services instead of requiring winston. This also means that it is easier to replace the logger implementation both in the future and for testing. Dgeni provides a "mock" logger at dgeni/lib/mocks/log, which you can require to override the standard winston logger.

  • Test coverage of the source files is now at 100%.

v0.4.0-rc.2 (10th September 2014)

Minor refactoring

  • chore(tests): move tests into lib folder 607037fe

v0.4.0-rc.1 (6th September 2014)

Minor refactoring

  • fix(Dgeni): handle validation and processor errors better b452b472

v0.4.0-beta.4 (1st September 2014)

Minor refactoring and fixes

  • feat(Dgeni): add configureInjector method 6a37dada
  • fix(gen-docs.js): remove unnecessary reference to base package b7d7185e
  • feat(gen-docs): add log option to CLI 062ca137
  • fix(gen-docs.js): startsWith() is not ES5 compatible 22e11630

v0.4.0-beta.3 (12th August 2014)

Minor refactoring

  • refact(Dgeni): remove dependency on 'es6-shim' and Map a8fa07eb

v0.4.0-beta.2 (7th August 2014)

Minor bug fixes

  • fix(Dgeni): require Package not package fc2be818
  • fix(Dgeni): do not modify package.dependencies property 61449389

v0.4.0-beta.1 (25th July 2014)

This is a major re-architecting of how Dgeni uses Dependency Injection and configuration.

This version of Dgeni is compatible with dgeni-packages@^0.10.0

  • Dgeni is now configured by Packages, which can depend on other Packages.
  • Packages contain Services, Processors and Config Blocks, which are all instantiated or invoked by the DI system.
  • Processors themselves are special instances of DI Service rather than the process() being invoked by the DI system.
  • Dgeni specific properties on Processors are now prefixed with a $. E.g. $process(), $runBefore, $runAfter.
  • Processors can now be "validated" using validatejs.org constraints, specified in the processor.$validate property.
  • Processors can now be disabled by setting processor.$enabled = false.
  • Processors with the same name will override previously registered Processors, say from a Package dependency.
  • New injectable helper services have been provided: dgeni, log, getInjectables.
  • Use injectable log service in your Processors and Services instead of requiring winston.
  • Test coverage of the source files is now at 100%.

The most significant commits are listed below:

  • fix(Dgeni): allow config blocks to change $enabled on a Processor d231c244
  • feat(Dgeni): allow processors to be disabled by setting $enabled: false d390fcd3
  • feat(Dgeni): allow config blocks to make changes to processor order 604fcbfb
  • feat(Dgeni): add package info to processors to help with error reporting 81184052
  • fix(Dgeni): processors with the same name should override previous ones ff7ec049
  • feat(getInjectables): add new shared service 6d9cef0a
  • test(mock/log): add simple mock log service for testing 51a8dc92
  • feat(Package): allow processors and service to override their name a9584fd2
  • test(Dgeni): add tests to improve code coverage 7b4a757b
  • feat(Package): allow processors to be defined as an object a75e9181
  • feat(Dgeni): add new (no config - DI based) Dgeni e8d30958
  • feat(Package): add Package type 87cbf122
  • feat(log): add wrapper around winston c303a9a6
  • refact(*): remove previous Dgeni implementation 1cf67e2d

v0.3.0 (11th April 2014)

This is a "Spring Clean" release

  • Configuration, utilities and dependencies that were only used by separate Dgeni packages have been moved to those repositories.
  • There is an initial set of "guide" documents to read at https://github.com/angular/dgeni/tree/master/docs/en_GB/guide.
  • The API has been cleaned up to make it easier to use Dgeni without having to look inside.

New Stuff

  • feat(doc-processor): processors can declare injectable exports cfd19f08

Breaking Changes

  • refactor(index): provide a cleaner API surface 3c78776d
  • refact(doc-processor): move pseudo processors to dgeni-packages c198f651

v0.2.2 (6th March 2014)

Bug fixes

  • fix(doc-processor): pass docs to next processor following a failure 67997e8e

v0.2.1 (5th March 2014)

Bug fixes

  • fix(doc-processor): handle errors thrown in processors better

v0.2.0 (28th February 2014)

New Features

  • extractTagFactory (lib/extract-tags.js) is moved to the dgeni-packages project.

BREAKING CHANGE

  • The extractTagsFactory is now moved to the dgeni-packages project, because it is specific to the way that tags are parsed and extracted in that project. If you rely on this then you should add dgeni-packages as a dependency to your project.

v0.1.1 (24th February 2014)

Bug fixes

v0.1.0 (20th February 2014)

  • Initial version to support AngularJS documentation generation.