npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2025 – Pkg Stats / Ryan Hefner

grunt-template-module

v0.5.1

Published

Precompile templates to a file with option to expose templates as a node/commonjs module.

Readme

grunt-template-module

Precompile templates to a file and/or expose the templates through a module.

This is an awful lot like the existing grunt-contrib-jst grunt task. But it has a few differences. One is that it supports underscore, lodash and ejs template providers. The real key feature is that it allows you to compile these templates into a module that exposes each compiled template from an exports property. What this means is that if you provide the following configuration:

template-module: {
    myTemplates:{
        files: {
            "tmp/module_jst.js": ["test/fixtures/template.html"]
        }
        options: {
            module: true
        }
    }
}

You would end up with an entry in module_jst.js that looks like:

exports["tmp/module_jst.js"] = function(obj){...

I know. You're wondering why do such a thing? Doesn't contrib-jst offer an AMD wrapper? Yes, it does, but it is a very noisy way to get at it on the server. As well, if you use browserify, this will play much better with the compiled browserified (is that a word?) output.

So there you have it. Browserify and server happiness for underscore/lodash and EJS templates. And backward compatibility with contrib-jst.

And one more thing: prettify uses beautify instead. Let's try that again. The prettify option in the original used some very simple code to pretty things up. Instead it now uses node-beautify.

Getting Started

If you haven't used grunt before, be sure to check out the Getting Started guide, as it explains how to create a gruntfile as well as install and use grunt plugins. Once you're familiar with that process, install this plugin with this command:

npm install grunt-template-module

template-module task

Run this task with grunt template-module at the command line.

This task is a [multi task][] so any targets, files and options should be specified according to the [multi task][] documentation. [multi task]: https://github.com/gruntjs/grunt/wiki/Configuring-tasks

Usage

template-module: {
  compile: {
    options: {
      module: true,
      provider: 'lodash'
    },
    files: {
      "path/to/compiled/templates.js": ["path/to/source/**/*.html"]
    }
  }
}

Options

module

Type: 'Boolean' Default: true

When true, the module behavior described above will be delivered with love and chocolate.

provider

Type 'String' Default: underscore

The name of the template engine to use. Allowable values are underscore lodash and ejs

useStrict

Type boolean Default: false

Enable strict mode by adding 'strict mode'; to the output

options: {
  useStrict: true
}

prettify

Type: boolean Default: false

When doing a quick once-over of your compiled template file, it's nice to see an easy-to-read format. This will accomplish that.

options: {
  prettify: true
}

prettifyOptions

Type: object

When you set prettify to true, you can pass options to the beautify module in this object.

options: {
  prettify: true,
  prettifyOptions:{
      indentSize: 4,
      indentChar: '\t',
      maxPreserveNewlines: 1
  }
}

single

Type: boolean Default: false

If enabled and there is only one soruce file, then export the template as a single function. e.g. module.exports = function( .... );

options: {
  single: true
}

namespace

Type: String Default: 'JST'

The namespace in which the precompiled templates will be asssigned. Use dot notation (e.g. App.Templates) for nested namespaces. This is not used when module is set to true.

processName

Type: function Default: null

This option accepts a function which takes one argument (the template filepath) and returns a string which will be used as the key for the precompiled template object. The example below stores all templates on the default JST namespace in capital letters.

options: {
  processName: function(filename) {
    return filename.toUpperCase();
  }
}

templateSettings

Type: Object Default: null

The settings passed to the template engine when compiling templates. The options are template engine specific.

template-module: {
  compile: {
    options: {
      templateSettings: {
        interpolate : /\{\{(.+?)\}\}/g
      }
    },
    files: {
      "path/to/compiled/templates.js": ["path/to/source/**/*.html"]
    }
  }
}

lintExpr

Type: Object Default: null

If you want to add a comment for lint or hint declarations, you can use this setting to declare the directives.

template-module: {
  compile: {
    options: {
     lintExpr : {
        unused : false,
        asi : true,
        expr : true
     },
    },
    files: {
      "path/to/compiled/templates.js": ["path/to/source/**/*.html"]
    }
  }
}

which would produce /*jshint unused:false, asi:true, expr:true*/ and add it to the bottom of the file.

requireProvider

Type: boolean Default: true

When compiling as with module: true, by default we'll prepend var _ = require('underscore'); to the output. This is fine if you're bundling your provider (underscore, lodash, or ejs) in your build.

However, you might not want to bundle your provider, for example if you want to load lodash from a CDN. In that case, you'll want to set requireProvider: false

amdWrapper

Type: boolean | string Default: false

With Require.js and a pre-compiled template.js you want the templates to be wrapped in a define. This will wrap the output in:

define(function() {
  //Templates
  return this["NAMESPACE"];
});

Example:

options: {
  amdWrapper: true
}

If you want a specific define, you can provide it as string:

options: {
  amdWrapper: 'define("templates", ["i18n"], function(__) {'
}

Will result in:

define("templates", ["i18n"], function(__) {
  //Templates
  return this["NAMESPACE"];
});
  • This is not used when module is set to true.*

Release History

  • 2012-12-24 v0.1.0 Initial release
  • 2012-12-25 v0.1.1 Fixed documentation and clarified names
  • 2014-06-12 v0.3.0 Updated dependencies