Vendoring

# esm.run bundles

jsDelivr serves one minified ES module per package, whatever the package ships on npm. --from esm.run vendors it.

## Bundles instead of dist files

[esm.run](https://www.jsdelivr.com/esm) is jsDelivr's bundling endpoint. Where jspm hands you a package's own `dist` file — unminified for plenty of packages, and split across several files for some — esm.run gives you one bundle, built with esbuild and minified:

```console
$ ./bin/importmap pin luxon --from esm.run
Pinning "luxon" to vendor/javascript/luxon.js via download from https://cdn.jsdelivr.net/npm/luxon@3.7.2/+esm
```

```ruby
pin "luxon" # @3.7.2 (esm.run)
```

The CDN is recorded in the pin comment, so `update` and `pristine` fetch the bundle again rather than jspm's file. See [Provenance](https://importmap-plus.zoolutions.llc/docs/provenance).

## Dependencies

A bundle references the packages it depends on as absolute `/npm/dep@1.2.3/+esm` imports, which only resolve on jsDelivr. When the bundle is vendored those imports are rewritten to bare specifiers — `import { Controller } from "@hotwired/stimulus"` — so they resolve through your import map, and every dependency without a pin is pinned the same way: vendored from esm.run, at the version the bundle was built against.

```console
$ ./bin/importmap pin stimulus-use --from esm.run
Pinning "stimulus-use" to vendor/javascript/stimulus-use.js via download from https://cdn.jsdelivr.net/npm/stimulus-use@0.53.1/+esm
Keeping existing pin for "@hotwired/stimulus" (bundle was built against @3.2.2)
```

A dependency you already pin is left alone: the bundle then resolves to whatever your import map says, exactly as a jspm download would. If a bundle imports the same package at two versions, the first one wins and the command says so — an import map holds one version per specifier.

> **Note:** The rewrite is lexical, not a JavaScript parser: it matches import or from followed by a quoted /npm/…/+esm specifier, so the same text inside a string or a comment would be rewritten too. In practice that doesn't come up — a jsDelivr bundle is esbuild output whose only surviving comment is the banner, and a root-relative /npm/ URL is meaningless anywhere but in one of its own imports.

## Versions and subpaths

Versions resolve through jsDelivr's data API, so a range and a subpath work the way they do on npm:

```shell
./bin/importmap pin luxon@3 --from esm.run
./bin/importmap pin apexcharts/core --from esm.run
```

## Without vendoring

With `--from esm.run --remote` the pin points at the bundle URL and its imports load from jsDelivr as-is — no rewrite, no dependency pins:

```ruby
pin "luxon", to: "https://cdn.jsdelivr.net/npm/luxon@3.7.2/+esm"
```