frontend-packagers

by wilmoore

Front-End Package Manager Comparison

447 Stars 24 Forks Last release: Not found 109 Commits 0 Releases

Available items

No Items, yet!

The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:

Front-End Package Manager Comparison

Why do this?

It is about time for front-end developers to have a decent package manager. Front-end development is serious business and there is no good reason for us to continue with sub-par tools or no tools at all.

I appreciate the effort that has gone into all of these. It is awesome to see really talented developers taking on the task and sharing the result with the rest of us.

Who are you?

  • I am a full-stack software developer
  • I love what I do
  • I love sharing what I've learned
  • Hit me up at @wilmoore, @github, and @linkedin

The contenders

The following tools have caught my attention:

NOTES:

  • component is more of a concept and a framework for building and distributing front-end components. If you'd like to read more on this distinction, check out the issue #1 thread.
  • bower is meant to be consumed by higher-level tools and frameworks. What this means in practice is:
    • (1) bring your own CJS/AMD loader.
    • (2) bring your own build tool.
    • (3) bring your own organization conventions.
    • (4) ultimately, coupled with either make or grunt, bower looks like a viable option

What is a package manager?

A package manager is a tool that allows you to specify a list of dependencies for your library or application. The tools depicted here are similar in scope to Bundler, NPM, or Composer.

How is this thing evaluated?

Since tool choice is extremely subjective, you (and/or your team) should come up with your own weighting system and score each tool accordingly.

Configuration File

The following table provides the name of the "manifest" file where you specify dependencies and/or the details of your package.

Configuration

bower component jam volo npm spm

filename
bower.json component.json package.json package.json package.json package.json

Sample bower enabled

bower.json
file:
{
  "name": "my-project",
  "version": "1.0.0",
  "main": "path/to/main.css",
  "ignore": [
    ".jshintrc",
    "**/*.txt"
  ],
  "dependencies": {
    "": "",
    "": "",
    "": ""
  },
  "devDependencies": {
    "": ""
  }
}

Sample component enabled

component.json
file:
{

"name": "tip", "repo": "component/tip", "description": "Tip component", "version": "0.0.1", "keywords": ["tooltip", "tip", "ui"], "dependencies": { "component/emitter": "", "component/jquery": "" }, "scripts": ["index.js", "template.js"], "styles": ["tip.css"]

}

Sample jam enabled

package.json
file:
{

"name": "csbp", "version": "0.0.1", "description": "A Non-Framework Client-Side JavaScript/HTML5 Project Boilerplate",

"dependencies": { "jamjs": "", "grunt-contrib": "" },

"devDependencies": { "chai": "", "mocha": "", "sinon": "", "grunt-mocha": "" },

"jam": { "packageDir": "src/libs/js", "baseUrl": "src/main/js" }

}

Sample volo enabled

package.json
file:
 {

"name": "csbp", "version": "0.0.1", "description": "A Non-Framework Client-Side JavaScript/HTML5 Project Boilerplate",

"dependencies": { },

"devDependencies": { "yeti": "", "docco": "", "jshint": "", "chai": "", "mocha": "", "sinon": "" },

"amd": {},

"volo": { "baseUrl": "src/js/lib",

"dependencies":  {
  "page":        "github:visionmedia/page.js",
  "requirejs":   "*"
}

}

}

Sample npm + browserify enabled

package.json
file:
{
  "name": "{{project}}",
  "version": "1.0.0",
  "description": "{{description}}",

"repository": "git://github.com/{{author}}/{{project}}.git", "main": "index.js",

"dependencies": { "hyperquest": "~0.1.0" }, "devDependencies": { "mocha": "*" },

"licenses": "MIT" }

Sample spm enabled

package.json
file:
{
  "name": "{{project}}",
  "version": "1.0.0",
  "description": "{{description}}",

"repository": "git://github.com/{{author}}/{{project}}.git",

"spm": { "main": "index.js", "dependencies": { "moment": "2.8.1", "jquery": "1.11.1" } },

"licenses": "MIT" }

NOTES:

  • There is an interesting discussion regarding some of the reasoning behind bower not supporting the well-known package.json format.
  • When using volo, I would suggest using the flags:
    • -nostamp
      : mitigates the reformating of your
      package.json
      file
    • skipexists
      : skip existing dependencies without noisy warnings
  • When using npm with browserify you can optionally add a
    "browser"
    field to
    package.json
    which overrides the
    "main"
    field. See the browser spec for more info.

Package Installation Location

The following table details where each tool stores downloaded packages.

Path

bower component jam volo npm + browserify spm

default path
./bowercomponents ./components ./jam ./js, ./scripts, ./ ./nodemodules ./spm_modules
custom path
.bowerrc --out dir jam.packageDir volo.{baseDir,baseUrl}, amd.baseDir - --outputDirectory dir

NOTES:

volo has a fairly complex algorithm.

If not defined in

package.json
it:
  • Looks for a ./js directory
  • Looks for a ./scripts directory
  • Otherwise, the current working directory is used

Development Dependencies

The following table details whether each tool allows specifying development dependencies.

Development Dependencies

bower component jam volo npm + browserify spm

devDependencies

NOTES:

  • Since jam, volo and npm use
    package.json
    , this just works; however, component re-implements this functionality here.

Responsibilities

The following table details the responsibilities the given tool takes on.

Responsibilities

bower component jam volo npm + browserify spm

package management
✓ (npm)
project bootstrapping
- -
project scaffolding
- - - - -
build automation
- - - - -
script/module loading
- - - -
compile/build
- - - ✓ (browserify)

NOTES:

  • Project bootstrapping (i.e.
    component create mycomponent
    ) is generally very minimal.
  • Project scaffolding (i.e.
    volo create username/template-repo
    ) can be a bit more involved.
  • An interesting comparison of volo and grunt.

Build/Compile

The following table details which tools require a build/compile step during development.

Build/Compile?

bower component jam volo npm + browserify spm

?
- ✓ (component build) - - ✓ (browserify) ✓ (spm build)

NOTES:

  • N/A

Central Registry

The following table details which tools expose a central "registry".

Registry?

bower component jam volo npm + browserify spm

?
-

NOTES:

Package installation sources

The following table details the method by which each tool allows you to specify each dependency (i.e.

dependencies
).

Source

bower component jam volo npm + browserify spm

git / github
✓ (CLI ONLY) -
private repositories
✓ (SEE NOTES BELOW) -
local repositories
- -
zip / tarball
- ✓ (CLI ONLY) ✓ (ZIPBALL ONLY) -
HTTP/HTTPS URL
- - - -
NPM
- - - -
registry
- - - -

NOTES:

  • I've never been on a serious team where no support for
    private repositories
    would be acceptable. If this is important to you, it seems that your best options are currently bower, component, jam and npm.
  • While volo doesn't actually claim to have explicit support for
    private repositories
    , you can achieve the notion of
    private repositories
    by providing a URL to a single JavaScript source file (github and github:enterprise allow you to link to a
    raw
    file) or you can specify a URL to a zipball. There are a few more tricks that you can choose from listed here.
  • You can setup a private jam free repo from garden20. Other details for a private repo can be found here.
  • Jam allows this
    jam install gh:visionmedia/page.js
    but only via the command-line (no package.json support).

Speed

The following table details the speed of each tool.

Registry?

bower component jam volo npm spm

~85 components
~80s ~10s ~80s ~80s ~40s ~20s

NOTES:

  • For most projects, speed won't be an issue; however, YMMV.
  • These benchmarks were taken from the component documentation; thus depending on your setup and dependencies, YMMV.

Supported JavaScript Module formats

The following table details the JavaScript format each tool expects/handles.

Format

bower component jam volo npm + browserify spm

Global Script
✓ (
--standalone
)
- -
AMD
✓ (format agnostic) ✓ (
--standalone
)
- -
CommonJS/NodeJS
✓ (format agnostic) ✓ (uses CJS style) - -
CommonJS (WRAPPED)
✓ (format agnostic) ✓ (
--standalone
)
- -

NOTES:

There are several JavaScript formatting methodologies:

  • Global Script

     
     
    
  • AMD

     define(['todo'], function(Todo){
        var todo = new Todo({description: '', done: false});
     });
    
  • CommonJS/NodeJS

     var Todo = require('todo');
     var todo = new Todo({description: '', done: false});
    
  • CommonJS (wrapped in an AMD-style define)

     define(function(require){
        var Todo = require('todo');
        var todo = new Todo({description: '', done: false});
     });
    

NOTES:

  • browserify supports transformations, which would make it simple to support other module formats

Module / Script Loader

The following table details the module/script loader supported by each tool.

Source

bower component jam volo npm + browserify spm

Bring your own loader
- - ✓ (can create multiple bundles) -
Includes a Loader
- ✓ (custom require) ✓ (RequireJS) - ✓ (Sea.js)

NOTES:

Loaders that you might be interested in:

Package Contents

The following table details the the types of source files that can be contained in each package per tool.

Source

bower component jam volo npm + browserify spm

JavaScript
HTML
- -
CSS
- -

NOTES:

  • npm lets you install any arbitrary files (much like bower) so you could bring your own loader for CSS and HTML.
  • browserify can facilitate loading static assets via brfs which analyzes the AST for fs.readFileSync() calls and inlines file contents. See comment by @substack for more details.

Final thoughts

Each package manager is built by talented, responsive, and friendly developers. Ultimately, to evaluate for your team, you will have to put a weight on each category and score per your needs.

Library and component authors may want to consider:

  • Using a UMD wrapper.
  • Authoring both a {component,package}.json for front-end and npm (where appropriate).
  • Adhering to these Library best practices or something similar.

Complementary Resources

Below is a list of resources that will likely be useful to you if you found this comparison useful:

Contributing

I am sure I've made a few grammatical and spelling errors. I've probably even made comparison errors in a few spots. Please feel free to speak up or submit a pull request.

Symbols Used

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.