JSPM: import map package management for the browser module era

The problem JSPM solves: browser resolution without a bundler

Native ES modules in the browser resolve bare specifiers badly. A browser will happily load ./lib/thing.js, but it will not resolve 'lodash' the way Node does, and it has no idea about package exports, conditional exports or version constraints. The usual answer is a bundler: flatten everything into one file and the resolution problem disappears. JSPM takes the other route. It keeps the modules separate and generates an import map, which is the browser standard that maps specifier strings to URLs. The README describes the project as "Package management tools for the JSPM project, supporting import map package management", and that framing is accurate: this is not a runtime, it is the tooling that produces and edits the map. The audience is narrow but real. If you are building a development server, a no-build frontend, a plugin host that loads third-party modules at runtime, or a tool that needs to resolve packages against a CDN, the resolution logic is the hard part and JSPM is that logic packaged up. If you are happy with a bundler, you are not the audience.

Three packages, one resolution model

The monorepo ships three libraries. cli is the jspm command line tool. generator is the import map generation library published as @jspm/generator. import-map is the low-level manipulation library published as @jspm/import-map. The split matters when you are deciding what to depend on. If you want a command you run in CI, you want the CLI. If you are embedding resolution inside your own tool, you want @jspm/generator, and the CLI becomes a thin wrapper you can ignore. If you only need to read, write and merge import map JSON without any resolution semantics, @jspm/import-map is the smaller dependency. The resolution model itself is the interesting part. The README lists "Universal Semantics", described as implementing universal CDN resolution semantics "based on an extension of the Node.js resolution". That is the design bet: instead of inventing a browser-specific resolution algorithm, JSPM extends the Node algorithm so that a package resolved locally and the same package resolved from a CDN produce equivalent mappings. On top of that sit conditional resolution (different versions of a module for different environments), dependency versioning (respecting version constraints in local and remote package.json files), and package entrypoints including node-style exports, imports and own-name resolution. Local Linking maps packages to your local node_modules folder, and the provider list covers jspm.io, jsDelivr, UNPKG and others via customProviders. Importmap Injection handles extraction and injection into HTML files, with module preloading and integrity attributes. Those last two features are the ones that turn the generator from a resolver into something you can put in a build step.

Installing the JSPM CLI and generating your first import map

The README does not contain install instructions; it points to https://jspm.org/getting-started and https://jspm.org/docs/cli/ for the CLI and https://jspm.org/docs/generator/ for the library. The repository layout confirms the package names, because the workspaces field in the root package.json lists import-map, fetch, generator, plugin-rollup and cli. Treat the package names as the reliable part and the exact commands as something to confirm against the CLI docs before you paste them into a pipeline. The generator is consumed as a library, and the entry point is the Generator class from @jspm/generator. A typical shape is to construct a generator, then tell it what to install and where the map should be written. The documentation gives this pattern for a Node project:

Where the design bites back

The import map is a build artefact with no version pinning of its own. JSPM resolves according to the constraints it finds, which means the map you generate today and the map you generate next month can differ even though nothing in your source changed, if a remote package published a new version inside your range. That is the same exposure you get from any lockfile-less resolution, but it is sharper here because the map is consumed directly by the browser at runtime. The README does not document a lockfile mechanism for the generated map, so the practical answer is to commit the generated map and diff it in review. The second limitation is browser support. Import maps are a platform feature; JSPM generates the map, but nothing in this toolchain can make a browser that does not support import maps understand one. If you need older browsers, you are back to a bundler or a polyfill outside this project's scope. The third is conceptual overhead. Conditional resolution and CDN resolution semantics are genuinely more machinery than "run esbuild". You are trading a bundler configuration for a resolution configuration, and if your dependency graph is small and your build is already fast, that trade is bad. Finally, the project's own build and test workflows use Chomp, so contributing means learning a second build tool on top of the npm workspaces.

JSPM against a conventional bundler

The honest alternative is a bundler such as esbuild, Rollup or webpack. The difference is not speed or output size, it is where resolution happens. A bundler resolves at build time and emits one or more files with no bare specifiers left, so the browser never needs a map. JSPM resolves at build time too, but it emits the map instead of inlining the graph, so the browser performs the final fetch and the module graph stays visible and individually cacheable. That has consequences in both directions. You get per-module caching and the ability to swap a mapping without rebuilding a bundle, which is useful for development servers and plugin hosts. You lose the guarantee that the graph is closed: a mapping can point at a URL that is unreachable in production, and the failure shows up in the browser console rather than at build time. Rollup specifically is close enough to this project that the monorepo includes plugin-rollup, which suggests the intended posture is coexistence rather than replacement. If you already use Rollup and only want import map output, that plugin is the smaller commitment.

Licence, maintenance and upgrade cost

The licence is Apache-2.0, stated in the README and present as a LICENSE file at the repository root. Apache-2.0 includes an express patent grant and requires that you preserve notices and state changes; it is permissive, so it does not force you to open your own source. Nothing here is legal advice, and if you redistribute the packages you should read the licence text rather than this summary. On maintenance: the repository is not archived, and the last push was on 2026-09-20. Recent releases include @jspm/[email protected] on 2026-06-29, 4.6.1 on 2026-06-21 and 4.5.0 on 2026-05-24. The version numbering is worth noticing: the generator is on a 2.x line while the CLI tags 4.x, so the two packages do not move in lockstep and an upgrade in one does not imply an upgrade in the other. Budget for reading release notes per package rather than treating the monorepo as a single versioned product. The dev dependency on typescript ^6.0.3 in the root package.json also means anyone building from source is on a fairly new compiler.

Editorial conclusion

Adopt JSPM if you ship native ES modules to browsers and want import maps generated from real package.json constraints rather than hand-written. Do not adopt it if your build already produces a single bundle and you have no intention of changing that, since the import map only pays off when the browser is doing the resolution. Before committing, verify the two things the README does not answer: which resolution mode your project needs (local node_modules or a CDN provider), and whether your target browsers support import maps at all, because nothing in this toolchain can polyfill that.

Frequently asked questions

Official sources

1. jspm/jspm on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases