Frictionless browser package management
* jspm is a package manager for the [SystemJS universal module loader](https://github.com/systemjs/systemjs), built on top of the dynamic [ES6 module loader](https://github.com/ModuleLoader/es6-module-loader)
* Load any module format (ES6, AMD, CommonJS and globals) directly from any endpoint such as `npm` and `github` with flat versioned dependency management. Any custom endpoints can be created through the Endpoint API.
* For development, load modules as separate files with ES6 and plugins compiled in the browser.
* For production, optimize into a bundle, layered bundles or a self-executing bundle with a single command.
* [jspm Getting Started guide in the Documentation Wiki](https://github.com/jspm/jspm-cli/wiki/Getting-Started)
<div style="text-align: center;">
<iframe width="560" height="315" src="http://www.youtube.com/embed/iukBMY4apvI" frameborder="0" allowfullscreen></iframe>
* [Package Management for ES6 Modules](https://www.youtube.com/watch?v=szJjsduHBQQ) JSConf 2014 presentation introducing jspm by [Guy Bedford](https://twitter.com/guybedford)
<div style="text-align: center;">
<iframe width="560" height="315" src="http://www.youtube.com/embed/szJjsduHBQQ" frameborder="0" allowfullscreen></iframe>
# Project Overview
jspm package management is designed around the [SystemJS dynamic ES6 loader](https://github.com/systemjs/systemjs).
* RequireJS-style module loader with similar configuration and [plugin system](https://github.com/systemjs/systemjs#plugins).
* Built on top of the [ES6 Module Loader polyfill](https://github.com/ModuleLoader/es6-module-loader), making it standards-compliant and future-friendly.
[Read more at the SystemJS project page on GitHub](https://github.com/systemjs/systemjs)
_Note that SystemJS is built on top of a draft module loader specification that is subject to change._
#### jspm CLI
* Uses flat version management to download into version-suffixed folders (eg `firstname.lastname@example.org`).
* Shares versions between dependencies, upgrading or downgrading dependency resolutions within their supported ranges to minimize forks during install.
* Because the CLI understands the loader, modular code works without the need for complex manual configuration.
[Read the CLI documentation on Github](https://github.com/jspm/jspm-cli)
Packages are universally named to an endpoint with the syntax `endpoint:package`.
_This syntax is only to be used when installing or testing packages on the CDN. For application code, we always use an alias to refer to modules for portability (`require('lodash')` over `require('npm:lodash')`)._
The following endpoints are currently supported:
* Most packages on npm will work naturally with full version management, with no further configuration necessary.
* The NodeJS builtins are provided by the same libraries used in Browserify.
* Packages on GitHub get their versions from semver tag names (with or without a `v` prefix).
* When a GitHub release for a given tag is provided, the release archive will be used instead of the repo.
* GitHub packages will benefit from jspm configuration being provided through the package.json or an override.
The [jspm registry](https://github.com/jspm/registry) provides a convenience mapping from shortcut names into full endpoint names.
This allows for easier installation - `jspm install jquery` over `jspm install github:components/jquery`.
jspm CLI provides a full version constraint solver when installing taking care to reduce forks.
The version solution is created as map configuration within the project configuration file. Each package can refer to dependencies as any custom name, since each package has its own internal naming map.
[jspm extends the package.json spec](https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm) with some new properties to understand how to treat packages.
Configuration options include the main entry point, module format, files and ignore rules, minfication, transpilation from ES6 to ES5, map config and dependencies (when combined with a registry property).
To provide configuration for existing libraries on GitHub or npm without access to the underlying repo, the jspm registry provides a [package.json override service](https://github.com/jspm/registry#packagejson-overrides).
The added benefit of using a flat versioned folder structure for dependencies is that packages can be hosted easily on a shared CDN for dynamic loading.
Since jspm assigns packages universal names, it is possible for endpoint CDNs to be provided that can be used by all users.
An experimental CDN serving the jspm registry, GitHub and npm endpoints is enabled on this site. To use it for development include:
in a page. Since sources are sent minified over HTTP/2, [depCache injection](https://github.com/jspm/jspm-cli/wiki/Production-Workflows#creating-a-dependency-cache) can even make this approach suitable for production.
The CDN can also be tested from this page - try opening up the browser console and using `System.import`. Some examples are included below.
**Loading NodeJS core browserify libraries**
console.log(new buffer.Buffer('base64 encoded').toString('base64'));
**Loading from npm**
console.log(_.max([1, 2, 3, 4]));