DecentCMS module manifests

In the previous post, I showed the basic structure of a DecentCMS module. In this post, I’ll start digging into the details by showing how a module can declare metadata about itself. The package.json file, also called "module manifest", is where DecentCMS module authors can declare what their module consists of. It is a standard NPM manifest file, with a few additional properties that DecentCMS understands.

Here is an example of a module manifest, taken from /modules/core/documentation:

{
  "name": "decent-core-documentation",
  "friendlyName": "Core Documentation",
  "version": "0.0.1",
  "description": "Online documentation for DecentCMS",
  "features": {
    "documentation": {
      "name": "Online documentation",
      "description": "Makes online documentation for all modules available under the /docs path."
    },
    "api-documentation": {
      "name": "Online API documentation",
      "description": "Makes online documentation extracted from JsDoc comments from libraries and services in all modules available under the /apidocs path."
    }
  },
  "main": "./index",
  "scripts": {
    "test": "./test/index"
  },
  "author": "Bertrand Le Roy",
  "license": "MIT",
  "dependencies": {
    "async": "*",
    "jsdoc-to-markdown": "*"
  },
  "devDependencies": {
    "chai": "*",
    "grunt-mocha-test": "*",
    "mocha": "*",
    "proxyquire": "*"
  }
}

The name property is the technical package name. I recommended that you use the "decent-" prefix for all DecentCMS modules, followed with the module area name if there is one, and then the name of the module. In the example above, "decent-core-documentation" is the name for the "documentation" DecentCMS module from the "core" area.

The friendlyName property is an addition from DecentCMS that may be used to give the module a more human-readable name than what the name property can give.

The features section describes all the features available in the module. A feature is a group of services that can be enabled and disabled for each site, through the site settings. Each feature has a name and a description. Features can declare their own dependencies, but I don’t recommended that you declare any. Instead, services should require other services, and fail gracefully when the required services can't be found. This contributes to loosening coupling.

The dependencies section is the standard NPM section where dependencies are defined. It should only mention dependencies on Node modules, not dependencies on other DecentCMS modules (see above).

The devDependencies folder is where NPM dependencies that are not required at runtime are declared. For example, libraries used only when testing or grunting the module can be declared here rather than in dependencies.

A DecentCMS module manifest is just an enhanced Node module manifest, as a DecentCMS module is just a kind of Node module. In the next post, I’ll show how to write an actual service, the next step in building a working module.