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 registry such as `npm` and `GitHub` with flat versioned dependency management. Any custom registry endpoints can be created through the Registry API.
* For development, load modules as separate files with ES6 and plugins compiled in the browser.
* For production (or development too), 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 `email@example.com`).
* Shares versions between dependencies, upgrading or downgrading dependency resolutions within their supported ranges to minimize forks during install.
* Because the installer understands the loader, modular code [including loader plugins](https://github.com/systemjs/systemjs#plugins), works with a single install and a single require.
[Read the CLI documentation on Github](https://github.com/jspm/jspm-cli)
jspm is designed to support any number of independent registries.
* All packages are universally named to a registry with the syntax `registry:package@version`.
* When importing external modules, we refer to them with an alias like `jquery`, which maps to the universal name in the background.
* Each package has its own map, allowing `jquery` to refer to different things for different packages and supporting multi-versions.
The following registries 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 registry names.
This allows for easier installation - `jspm install jquery` over `jspm install github:components/jquery`, and provides the default aliasing.
jspm CLI implements shortest-path fork reduction during installs, while ensuring targets are at their latest patch versions to reduce bugs.
The version solution is created within the project configuration file, and can be checked-in to version control to lock dependencies.
[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, 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 registry CDNs to be provided that can be used by all users.
An experimental CDN serving the jspm registry, GitHub and npm registries is provided through jspm.io. 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]));