Load npm packages in modern browsers with the native browser ES module loader:
<script type=module>
import React from 'https://dev.jspm.io/react';
</script>
Or with the dynamic import()
(try it out in the console if using Chrome):
import('https://dev.jspm.io/react').then(({ default: React }) => console.log(React));
CommonJS modules only export a default
export, to support the currently intended NodeJS interop with ES modules. This support will track whatever module interop NodeJS implements here.
Easy Web Prototyping and Development
As of 9 May 2018, all modern browsers now support loading ES modules via the <script type="module">
tag.
jspm.io enables development workflows to utilize this module loader to load existing npm packages as ES modules.
Being able to skip bundler and tooling setup to easily work with the npm package ecosystem provides a simple prototyping workflow for the web.
There is no need to lookup CDN URLs or work out how to get CDN scripts to work together as all modules share the same native registry in the browser while following the npm package ecosystem semantics you'd get with a bundler.
Not for Production
These workflows are intended for development only as serving 100's or even 1000's of modules is not suitable for production.
The server at https://dev.jspm.io
serves modules unminified and with process.env.NODE_ENV=dev
.
To load packages with process.env.NODE_ENV=production
, you can use https://unsafe-production.jspm.io
.
For future production workflows, the jspm package manager aims to provide workflows for bridging the gap between CDN delivery and offline package management through package import map generation while retaining the same semantics.
Features
Modules are all served as separate files over HTTP/2 with CDN edge caching.
Far-future expires are provided for exact package versions for fast reloads.
ES modules are supported as
.mjs
or when usingimport
andexport
statements.Packages are processed as they are requested - the first load of a new package may take a few moments, but after that it will be cached at the edge of the network.
Common Framework Examples
The following are simple HTML examples of common frameworks on Plnkr using a single HTML page with a <script type=module>
tag:
If you'd like to share or update an example, please post a website issue.
URL Formats
The following URL formats are supported:
- Latest Version:
https://dev.jspm.io/package-name(/path)?
- Version Range:
https://dev.jspm.io/package-name@versionOrRange(/path)?
- Canonical Form:
https://dev.jspm.io/npm:package-name@exactVersion(/path)?
Supported version ranges are @X
, @X.Y
, @X.Y.Z
or the exact version. Semver symbols are not supported - instead of @~1.2.3
use @1.2
and instead of @^1.2.3
use @1
rather.
The canonical form is the URL at which the actual source will be provided, with version and name aliases working via redirects and modular redirects.
How it Works
CommonJS modules are converted into ES modules by using a code transform called a Deferred Execution Wrapper (dew transform).
This transform ensures the CommonJS execution semantics, while also providing a best-effort strict mode conversion where necessary.
Package dependency resolutions are inlined during this transform process to their version alias URLs.
In order to avoid the latency waterfall of module loading, deep dependencies are inlined as imports within alias modules.
Reporting Issues
If a package or module is not loading correctly, and it is expected to work through a bundler, please post a project issue.
Note that GitHub or other non-npm dependencies are not currently supported.