Important: This documentation covers Yarn 1 (Classic).
For Yarn 2+ docs and migration guide, see yarnpkg.com.

Package detail

orchid-lead

orchid-lead9MIT3.1.3

Generate HTML files from Handlebars templates with data from node.js modules or JSON data files.

block, extends, handlebars templates, handlebars, hbs, html generator, inheritance, jade, layout, mustache, pug, static site generator, template inheritance, templates

readme

Orchid Lead

Generate HTML files from Handlebars templates with data from node.js modules or JSON data files.

npm version dependencies dev dependencies npm downloads per month npm license

Orchid Lead is a program focused on doing one thing well: generating HTML† files from templates and data, in this case, Handlebars templates and JSON data. Orchid Lead is a static site generator, without all the cruft and requirements of other static site generators because it focuses on the HTML and the data.

Notably, Orchid Lead doesn't dictate a particular build tool. It integrates with your current build tools like Gulp, Brunch, NPM, or even make. It gathers the data and runs it through the Handlebars template, along with helpers, partials, and [layouts][waxon] to generate the final output file in the build folder.

While Orchid Lead can copy static assets from the source folder to the build folder, it doesn't do that by default because there are already excellent tools for handling JavaScript and CSS, like Babel and PostCSS.

Orchid lead also focuses on speed, especially, speed of development. With an off-the-shelf file system watcher, the excellent Chokidar, Orchid Lead is able to quickly and reliably rebuild output files as the sources change. This feature is best paired with Browsersync or LiveReload so the changes appear instantly in your browser.

† HTML is the primary use case, but technically, any plain text file will work.

Install

If you already have node.js installed, then simply use npm to install orchid-lead. Note, installing the command globally makes setting up a new project easier, but is not required.

npm install orchid-lead --global

Setup

If Orchid Lead is installed globally and you don't want to change the defaults then setting up a new project is as easy as:

orchid-lead init new-dirname
cd new-dirname

Or, initialize and existing directory:

cd existing-dirname
orchid-lead init

This will install the default starter kit into new-dirname and existing-dirname, respectfully. If you'd like to use a different starter kit then just add the --with argument and a GitHub repo reference.

orchid-lead init --with orchid-lead/starter-kit-default new-dirname
cd new-dirname

Usage

For regular development use the watch sub-command and it will monitor the source files for changes and regenerate the output files on-demand.

orchid-lead watch

Or, generate the output files once with the build sub-command.

orchid-lead build
`

To generate all output files once and continue monitoring the source files for changes, use the watch sub-command with the --initial option.

orchid-lead watch --initial

To generate all output files after every change to the shared source files (helpers, layouts, and partials), then add the --rebuild-all option to the watch sub-command. Otherwise, the default is to only generate output files for the sources files that have changed since the program begin.

orchid-lead watch --rebuild-all

Optionally, you can specify the specific source files to regenerate with a [glob][glob] pattern.

orchid-lead build "site/pages/**/*.hbs"
`

Or, a normal file path.

orchid-lead build site/pages/index.hbs
`

Handlebars Templates

All templates should be written in Handlebars.

Handlebars provides the power necessary to let you build semantic templates effectively with no frustration.

The default build will look for all Handlebars files with the hbs extension and execute them with their related [data context][#data-context].

Handlebar templates with filenames that exactly match their parent directory name will be output as index.html files.

Note, templates do not have to be HTML, any plain text file can be templated with Handlebars. For example, use robots.txt.hbs to generate robots.txt from a template with a dynamic data context.

Orchid Lead automatically registers all helper files in site/helpers (default) and all partial files in site/partials (default), so those helpers and partials are available in every tempalte. Orchid Lead also includes the Wax On Handlebars helpers to allow templates to be extended with other templates, known as layouts. All layout files are found in site/layouts by default.

Data Context

Orchid Lead builds the a data context for each template it executes. It will pull in data from the following locations:

  1. A YAML block at the top of the tempalte file (a.k.a. front matter)
  2. A nearby data file
  3. The site-wide data file

Front matter is the easiest way to associate data with a template. The front matter must be formatted as a YAML block. Here's an example:

    ---
    title: Welcome to Company, Inc.
    description: At Company, we make the best gadgets.
    ---

Note, the data context is shared with Handlebars layouts and partials, so front matter is a great way to share data specific to template with a layout or a partial. Don't forget, Orchid Lead includes the Wax On Handlebars helpers to extend templates and layouts with template inheritance.

Orchid Lead will also look for a nearby data file. The data file may be a static JSON data file or a dynamic JavaScript data file. The data file should have the same basename as the template, but end in either data.json or data.js. The JavaScript data file must be a node module that returns a plain-old JavaScript object or a Promise.

Sample data.js file (sync)

    // data.js (sync)

    function calc() {
        return 2 + 2;
    }

    module.exports = {
        result: calc()
    };

Sample data.js file (async)

    // data.js (async with promises)
    var request = require("request");

    module.exports = new Promise((resolve, reject) => {
        let data = {};

        request("http://www.google.com", function (error, response, body) {
            if (err) {
                reject(err);
            } else {
                if (response.statusCode == 200) {
                    data.googleHtml = body;
                    resolve(data);
                } else {
                    reject(new Error(`Invalid status code ${response.statusCode}`));
                }
            }
        })
    });

Site wide data is pulled in from site/data.js. All site-wide data is available under the site object in the Handlebars data context. The nearby data file and the front matter are merged together and available under the page object in the Handlebars data context.

Configuration

The orchid-lead command accepts the following arguments.

-C, --config <path>  path to config file
--output <path>      path where output files are saved
--site <path>        path to site
--helpers <path>     path to helpers
--layouts <path>     path to layouts
--pages <path>       path to pages
--partials <path>    path to partials

The default config filename is .orchidleadrc and the default location is in the project folder. The file is saved in JSON format. Note, command line arguments override the config file settings.

Options

Optionally, orchid-lead can save a file with a list of timestamps for all the pages it encounters with a publication date in the future, in the data context. The publication date key may be any of the following and it's value must be an ISO 8601 formatted date string.

  • publicationDate
  • publication_date
  • publication date
  • publication:date

The filename is currently hardcoded to .future-publication-dates. The timestamps are formatted as an integer with the number of seconds since the Unix Epoch, followed by the same timestamp in a more human friendly format. Each record is separated by a new line character. For example:

1506862800 Sun Oct 01 2017 06:00:00 GMT-0700 (PDT)
1507561200 Mon Oct 09 2017 08:00:00 GMT-0700 (PDT)

Todo

  • remove sync functions and use more Promises
  • fix bug reading .orchidleadrc file from alternate path
  • allow default config to be overridden
  • ask user where they'd like their files to be during init
  • add clean sub-command for removing generated files
  • test performance
  • create JS API to ease use with Gulp
  • check for existing install before initializing
  • create sub-command (or option) to generate a list of all output files that would be generate but do not actually generate them

Please create a new issue if you find a bug or would like to recommend a new feature.

Change Log

The Orchid Lead change log can be found in the CHANGELOG.md file within the project.

License

Orchid Lead is available under the MIT License.

changelog

Orchid Lead Change Log

v3.1.3— April 8, 2020

  • updated dependencies to resolve security issues
  • updated all dependencies to latest version
  • removed dependency on (the deprecated) request module

v3.1.2— October 21, 2019

  • updated all dependencies to latest version
  • removed unnecessary try/catch block

v3.1.1— October 21, 2019

  • updated dependencies to resolve security issues

v3.1.0— June 10, 2019

  • improved debugging with stack traces when more errors occur

v3.0.2— March 28, 2019

  • fixed bug to reload helpers and partials from the file system when a shared source file changes

v3.0.1— March 27, 2019

  • updated dependencies

v3.0.0 — March 27, 2019

  • when a change to a shared source file is detected, only output files for source files that have changed since orchid-lead was started will be regenerated.
  • the old behavior of regernerating all output files can be restored by using the --rebuild-all option to the watch sub-command.

v2.5.0 — October 16, 2018

  • added feature to build all templates in the same folder as the file that changed when watching
  • added feature where data contexts are uncached when not in production environment
  • fixed a bug where changes to data.json files did not compile the related template
  • upgraded dependency: front-matter

v2.4.2 — October 16, 2018

  • added option to watch command to run the initial build on start

v2.4.1 — June 13, 2018

  • increased minimum version of lodash library to address vuln

v2.4.0 — June 13, 2018

  • added Q promises library for Q.allSettled and Q.promisify
  • wait until all pages are built before wrapping up, even if there's an error

v2.3.1 — June 5, 2018

  • debounce the callback for change events for files that require a full build

v2.3.0 — April 19, 2018

  • per-page data context is loaded into the root data context instead of under the page property, accessing the page property is deprecated
  • page output path is available in the global __path variable in the data context, the page.path property is deprecated
  • no longer overrides global fs methods with graceful-fs, only local
  • no longer re-builds the Handlebars template file when a nearby CSS or JS file is updated
  • fixed bug where an error was reported for pages that should not be built in orchid-lead watch
  • improved consistency of relative paths in log

v2.2.3 — April 13, 2018

  • added code the always strip "index.html" from the page path variable in the data context

v2.2.2 — February 8, 2018

  • dependencies were updated to their latest

v2.2.1 — October 5, 2017

  • changed format of human readable date string in future pubs file
  • improved documentation of this option

v2.2.0 — September 28, 2017

  • added option to output file containing a list of future publication dates
    • this can be used to schedule builds
  • refactored more loops with async functions to use Promises
  • copying static files and saving future pub dates are now down after building is completed
  • added log message when everything is done building
  • updated orchid-lead watch to "gracefullify" all calls to fs
  • added code to ignore data.js files during an add event
  • refactored registerPartials function to use glob to find all partial files instead of homemade recursive fuction that didn't recurse more than one level.

v2.1.4 — June 13, 2017

  • allow constructor to be called without options

v2.1.3 — June 8, 2017

  • switched to using graceful-fs to prevent EMFILE errors
  • changed log level for file copied and file added form info to debug

v2.1.2 — May 11, 2017

  • fixed bug when processing an array to data contexts that lead to first context to resolve to be the only file reportedly created
  • properly log each file built
  • sorted the output paths when building an array of data contexts

v2.1.1 — March 28, 2017

  • improved error handling

v2.1.0 — February 6, 2017

  • added page output path to data context before rendering

v2.0.0 — January 19, 2017

Breaking Change: many API methods are now async to support async data.js with Promises. Note, the command line interface has not changed.

  • allow for async data.js files with Promises

v1.1.0 — October 21, 2016

  • save config file with indentation
  • moved some shared code into a library
  • added task to lint JS files
  • fixed another bug when coping static files

v1.0.1 — October 21, 2016

  • fixed bug when coping static files

v1.0.0 — September 21, 2016

  • initial version for public release