importmap-plus 1.0.0 → 2.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: fea391704872c66da12c98d005e02ee2090282b4d7ce6065d46e6418ac4ca51e
-  data.tar.gz: a7bf185de0f21d3833eef1faa4d488b17f70779a744131033a1b74418c4ee194
+  metadata.gz: a89ba9297f9e04e1f3a892ea319d509ce9300789f648327c3b4b1cf72c0951d7
+  data.tar.gz: c088e5ab5732c9f132bfa63a60d2a7d9243ac85690670e1a040e3658fc1fb091
 SHA512:
-  metadata.gz: 2cf5e806291fd73a078b390e3cff8aeccd628cc61dfba53469081dec8951cde3a8380009ca9e7f0898c4a17b022ace9b7296f35576ffba0517ca57f2608ca42c
-  data.tar.gz: 13dc2bd3db6f202d60ad3752a33edcdd4e32a1e887cad34bc79f4eb5c9d54cb1582e9799f0af03d273309444b60c56bcba47e44057baf87af08464158b442ff4
+  metadata.gz: 81f2d28ee6c2d724917e338451d4a0f2baef86feb1bcc5477feca8114f13213787d9164b6befc8e7e02cf24e5ec0f810e13d05195be4e27c689bc70db5fd9311
+  data.tar.gz: 3cbd693b24887409203b8f75294798c3ee4b08dec82a90eb404de2a24e7ba7f273d4babd48a72c3a1608f8f263b4804b27dcfbf624edbb69252ea8ea6b346d63

data/CHANGELOG.md

@@ -1,5 +1,425 @@
 # Changelog
 
+## 1.2.0
+
+### Added
+
+- **`pin` resolves the version on the npm registry, then falls back from jspm
+  to esm.run to jsDelivr.** jspm is the default CDN and was the only one `pin`
+  asked, so a package its generator can't build — `mermaid@10.6.0` fails on a
+  cytoscape subpath, `@mui/material@5.15.0` on a module it can't find — ended
+  in `Couldn't find any packages`, and a bare `pin foo` took whatever version
+  jspm had indexed, which lags npm. A package that names no CDN of its own is
+  now asked of each in turn, and its version is settled against the registry
+  before any of them is asked:
+
+  ```
+  $ bin/importmap pin mermaid
+  Resolved "mermaid" to 10.6.0 from the npm registry
+  jspm couldn't resolve "mermaid@10.6.0" (No './dist/cytoscape.umd.js' exports subpath defined in cytoscape@3.34.3); trying esm.run
+  Pinning "mermaid" to vendor/javascript/mermaid.js via download from https://cdn.jsdelivr.net/npm/mermaid@10.6.0/+esm
+  ```
+  ```ruby
+  pin "mermaid" # @10.6.0 (esm.run)
+  ```
+
+  The pin comment already records a CDN that isn't jspm, so `update` and
+  `pristine` stay on esm.run from then on with no new state anywhere. An
+  explicit `--from`, and a provider a pin already names, are choices somebody
+  made: those are asked once and never fall back. When no CDN has the package,
+  each one's reason is printed and the summary names all three.
+- **A download that isn't an ES module is kept remote instead of vendored.**
+  The CDNs that serve a package's own `dist` file hand back the UMD bundle
+  plenty of packages still publish; vendored into an import map it runs and
+  exports nothing, so `import x from "pkg"` fails to link in the browser and
+  nowhere else. `pin google-libphonenumber --from jsdelivr` now keeps the pin
+  remote and records `(remote: not an ES module)`. `--vendor` downloads it
+  anyway, and the default `pin` never sees it, since jspm converts the package.
+- **The CDN's own reason reaches the terminal.** jspm answers 401 with its
+  generator's message in the body, which `pin` discarded: `Couldn't find any
+  packages in ["mermaid@10.6.0"] on jspm` said nothing about what went wrong.
+  That message is now printed with the sentence, whichever CDN was asked.
+
+- **`pin` keeps a package remote when its file can't stand alone, and says
+  why.** A vendored package is one file served under a digested asset path,
+  but plenty of packages ship a file that imports a sibling by relative path,
+  spawns a `Worker`, reads `import.meta.url` or fetches a `.wasm` binary —
+  every one of those 404s in the browser, and importmap-rails vendors it
+  anyway. `pin` now reads the download before writing anything to
+  `vendor/javascript`; a file that needs more than itself is pinned to its CDN
+  URL and the reason goes on the pin:
+
+  ```
+  $ bin/importmap pin fflate@0.8.2
+  Pinning "fflate" to https://ga.jspm.io/npm:fflate@0.8.2/esm/browser.js (kept remote: workers)
+  ```
+  ```ruby
+  pin "fflate", to: "https://ga.jspm.io/npm:fflate@0.8.2/esm/browser.js" # @0.8.2 (remote: workers)
+  ```
+
+  The pin then behaves like any other remote pin — `pin` and `update`
+  re-resolve it from the same CDN and keep the reason, `pristine` skips it.
+  `pin --vendor` downloads the package anyway and records `(vendored)` on the
+  pin, so a later `update` doesn't undo the override; it also converts a pin
+  that was kept remote back to a download. Nothing an app already vendored is
+  rewritten on its own — `pristine` redownloads those pins as it always has —
+  but the next `pin` or `update` that touches one re-resolves it, and a package
+  whose file can't stand alone converts to a remote pin then. That is the fix
+  arriving, not a surprise: the vendored file it replaces was already 404ing
+  for its siblings. pdf.js is the package most apps will see this on — see
+  the upgrading page for what to expect and how `--vendor` puts it back.
+
+- **A pin that stays remote carries a subresource-integrity hash.** A vendored
+  file is served by the app; a remote pin is fetched from a CDN on every page
+  load with nothing checking the bytes, and importmap-rails never wrote an
+  `integrity:` value for one — the hash had to be computed by hand and redone
+  on every update. `pin --remote`, and a package [kept remote] because its file
+  can't stand alone, now fetch the URL they just resolved, hash it and write it
+  with the pin:
+
+  ```
+  $ bin/importmap pin md5@2.2.0 --remote
+  Pinning "md5" to https://ga.jspm.io/npm:md5@2.2.0/md5.js (integrity sha384-+wqk6m3DPZ6mVMgVZlXnGgDjDY2skGEZ3U9tBnRHiPJXLRLKBmYkKlX2urz9T61b)
+  ```
+  ```ruby
+  pin "md5", to: "https://ga.jspm.io/npm:md5@2.2.0/md5.js", integrity: "sha384-+wqk6m3DPZ6mVMgVZlXnGgDjDY2skGEZ3U9tBnRHiPJXLRLKBmYkKlX2urz9T61b"
+  ```
+
+  The hash is `sha384` of the bytes the CDN served, computed here rather than
+  asked of any one CDN, so jspm, esm.run, jsDelivr, unpkg, esm.sh and skypack
+  are all covered by one code path. `update` and a later `pin` fetch the new
+  URL and rewrite the hash, so a pin never carries the hash of a file it no
+  longer points at — where before an explicit hash was simply dropped.
+  `enable_integrity!` in `config/importmap.rb` is still what puts the value in
+  the import map and on the preload link; `--no-integrity` skips the fetch for
+  a run, and `integrity: false` on a pin stays off for good. Vendored downloads
+  are unaffected: `integrity: true`, the default, already computes theirs
+  through the asset pipeline.
+
+  [kept remote]: https://importmap-plus.zoolutions.llc/docs/pinning
+
+- **`pin` vendors a package's whole file graph, so a chunked package no longer
+  needs a CDN at runtime.** A package whose entry imports a sibling by relative
+  path — `@popperjs/core`, `date-fns`, `lodash-es`, and every package built by
+  a bundler that splits chunks — could not be vendored: the browser resolves
+  `./enums.js` against a digested asset path, and neither Propshaft nor
+  Sprockets rewrites `import` statements. Those packages were [kept remote].
+  `pin` now downloads the closed set of files the entry reaches, rewrites every
+  relative specifier to a bare key, and maps the directory with one
+  `pin_all_from` line:
+
+  ```
+  $ bin/importmap pin @popperjs/core@2.11.8
+  Pinning "@popperjs/core" to vendor/javascript/@popperjs/core.js via download from https://ga.jspm.io/npm:@popperjs/core@2.11.8/lib/index.js (with 47 sibling files)
+  ```
+  ```ruby
+  pin "@popperjs/core", to: "@popperjs--core.js" # @2.11.8
+  pin_all_from "vendor/javascript/@popperjs--core", under: "@popperjs/core", to: "@popperjs--core" # @2.11.8 (graph of @popperjs/core)
+  ```
+
+  The entry keeps the flat file and the plain comment it always had, so
+  `update`, `outdated`, `lock` and `pristine` read it exactly as before, and a
+  `config/importmap.rb` written this way still parses under importmap-rails.
+  Bare specifiers are untouched, and a file that is another pin's own entry is
+  rewritten to that pin's key rather than copied, so the browser evaluates each
+  module once. (Two pins of one package do each carry their own copy of a chunk
+  they share; both write it under the same key, so one of the copies is what
+  every importer gets and the other is dead weight.) `unpin` takes the directory and the line with the pin,
+  `pristine` rebuilds the directory, `pin --minify` minifies every file in it,
+  and `pin --vendor` downloads the entry on its own and drops the directory and
+  line it had. A directory the import map doesn't map as one of ours is the
+  app's: `pin` says so, writes nothing rather than renaming it away, and exits
+  non-zero — as it does when a CDN fails partway through a crawl, where the pin
+  and the files it had are left exactly as they were.
+
+  Only jspm, jsDelivr and unpkg are crawled — their URLs say where a package's
+  directory ends. A graph that can't be taken over whole (a relative path that
+  climbs out of the package, a sibling the CDN hasn't got, a sibling that isn't
+  JavaScript, two files that would collapse to one key) keeps the whole package
+  remote, as does a download that also spawns a worker, reads
+  `import.meta.url`, computes an `import()` or names a `.wasm` file. A pin
+  importmap-plus had kept remote for its relative imports is converted back to
+  a download by the next `pin` or `update`, on the CDN its URL names.
+
+  Two things `pin` says out loud rather than doing quietly: a key some other
+  package's graph already maps (a directory wins over a pin, so the pin would
+  do nothing), and a second directory mapping a package one already maps at
+  another version (a file they share resolves to one of them).
+
+- **`bin/importmap doctor` checks an app's import map and vendored files,
+  offline.** `audit` and `outdated` ask the npm registry about your packages;
+  nothing asked whether the map still matched the files in the repo. A pin
+  whose file had gone missing, a vendored file importing a bare specifier
+  nobody pinned, a vendored file still importing the siblings it was downloaded
+  beside, a CommonJS bundle a CDN handed back — each of those said so in the
+  browser and nowhere else. `doctor` boots the app and reports them:
+
+  ```
+  $ bin/importmap doctor
+  error    pin "not_there" → nowhere.js: no such asset
+  error    vendor/javascript/shoelace.js imports "lit/decorators.js", which isn't pinned
+  error    vendor/javascript/popper.js imports "./enums.js" by relative path — run bin/importmap pin @popperjs/core to vendor its files
+  warning  vendor/javascript/old-lib.js isn't pinned by anything
+  warning  "@hotwired/turbo" and "@hotwired/turbo-rails" both resolve to turbo.min.js
+  3 errors, 2 warnings
+  ```
+
+  Errors exit 1, so it belongs in CI beside `audit` and `outdated`; warnings —
+  a file nothing serves, including a `.mjs` that `pin_all_from` never picks up,
+  and two keys on one file or one package vendored at two versions — leave the
+  exit status alone. It reports and never edits: `pin`, `unpin` and `pristine`
+  are what fix what it finds.
+
+  `--online` adds the one check that needs the network, fetching every remote
+  pin to report one the CDN no longer serves and an `integrity:` hash that
+  doesn't match the bytes it does serve. Every other check reads only the map,
+  the asset paths and the files on disk, so the default is fast and can't fail
+  because a CDN is having a bad afternoon.
+
+- **`config.importmap.preload_strategy = :reachable` preloads what the entry
+  point actually reaches.** Every pin with `preload: true` gets a modulepreload
+  link on every page, so a package the app only loads with `import()` is
+  fetched up front anyway unless someone writes `preload: false` on it — and on
+  everything it depends on, and keeps that list right as the package changes.
+  An app on this gem carried the comment "imported only by apexcharts.js, which
+  is itself lazy. Without it, 1.1 MB was preloaded on every page."
+
+  The import graph already knows. `app/javascript`, `vendor/javascript` and
+  every `pin_all_from` directory are files on disk, and their `import`
+  statements name pin keys:
+
+  ```ruby
+  # config/application.rb
+  config.importmap.preload_strategy = :reachable
+  ```
+
+  `javascript_importmap_tags "application"` now emits a link only for the pins
+  `application` reaches through **static** imports, however deep. A dynamic
+  `import()` is the lazy boundary and contributes nothing — preloading its
+  target is the deferral the app asked for, undone. A pin naming an entry point
+  (`preload: "admin"`) is preloaded whether or not the graph reaches it, which
+  is the escape hatch for a specifier no regex can see; `preload: false` stays
+  off either way.
+
+  Nothing new happens on the request path: the files are the ones the asset
+  pipeline already serves, read once per import map cache generation and
+  dropped by the same sweeper that drops the rendered map when a `.js` file
+  changes. The default `:all` — upstream's behaviour, one link per
+  `preload: true` pin — is unchanged and never opens a file.
+
+- **`javascript_importmap_tags` sends its modulepreload links as 103 Early
+  Hints.** A modulepreload link is markup, so the browser can only act on it
+  once the HTML has streamed far enough to be parsed — the whole module graph
+  waits on the response. The same list now goes out ahead of it as a `Link`
+  header, and the fetches start while the app is still rendering:
+
+  ```
+  HTTP/1.1 103 Early Hints
+  Link: </assets/application-abc.js>; rel=modulepreload, </assets/@hotwired--stimulus-def.js>; rel=modulepreload
+  ```
+
+  Exactly the modules the tags preload, so `preload: false`, an entry point's
+  own list and `preload_strategy = :reachable` all narrow the hinted set with
+  the tags. No `integrity` parameter: browsers don't honour one on a `Link`
+  header, and the tag in the body still carries it.
+
+  This is what Rails' own `javascript_include_tag` and `stylesheet_link_tag`
+  already do, and it needs what they need — a server that puts
+  `rack.early_hints` in the env, which Puma does with `early_hints true`. On a
+  server without it, `send_early_hints` is a no-op and nothing changes. Off
+  with `config.importmap.early_hints = false`.
+
+### Changed
+
+- **Everything this gem knows about esm.run lives in `Importmap::EsmRun`.**
+  The provider name, the bundle URL shapes, the rewrite that turns a bundle's
+  `/npm/dep@ver/+esm` imports into bare specifiers and the jsDelivr version
+  lookup were nine things in `Importmap::Packager`, which had grown to the
+  800-line ceiling with nowhere to put the next addition. Behaviour is
+  unchanged and no documented setting moved: `Importmap::Packager.esm_run_resolver`
+  still reads and writes the resolver, now on the new class. Only the `:nodoc:`
+  constants `Packager::ESM_RUN_*` are gone, as `Importmap::EsmRun::PROVIDER`,
+  `::CDN`, `::URL_REGEXP` and `::IMPORT_REGEXP`.
+
+### Fixed
+
+- **One package a CDN can't resolve no longer blocks — or silently moves — the
+  rest of the batch.** ([#32](https://github.com/zoolutions/importmap-plus/issues/32))
+  A CDN answers a batch of packages as a whole, so `bin/importmap update` with
+  three outdated packages reported `Couldn't find any packages in
+  ["cheap-ruler", "mapbox-gl", "mermaid"] on jspm`, updated nothing and exited
+  0, because jspm's generator can't build `mermaid`. Commenting out the one
+  package let the other two through. A refused batch of more than one package
+  is now asked for one package at a time, along the path each would have taken
+  alone:
+
+  ```
+  $ bin/importmap pin md5@2.2.0 mermaid@10.6.0
+  jspm couldn't resolve "md5@2.2.0", "mermaid@10.6.0" (No './dist/cytoscape.umd.js' exports subpath defined in cytoscape@3.34.3); asking for each on its own
+  Pinning "md5" to vendor/javascript/md5.js via download from https://ga.jspm.io/npm:md5@2.2.0/md5.js
+  jspm couldn't resolve "mermaid@10.6.0" (No './dist/cytoscape.umd.js' exports subpath defined in cytoscape@3.34.3); trying esm.run
+  Pinning "mermaid" to vendor/javascript/mermaid.js via download from https://cdn.jsdelivr.net/npm/mermaid@10.6.0/+esm
+  ```
+  ```ruby
+  pin "md5" # @2.2.0
+  pin "mermaid" # @10.6.0 (esm.run)
+  ```
+
+  Only the package the CDN refused travels the rest of the chain, so a healthy
+  package is never re-pinned from another CDN — and never has its provenance
+  comment rewritten — because a sibling failed. An explicit `--from`, or a
+  provider a pin records, still asks that one CDN and only that one, now once
+  per package. The batch stays the fast path: it is split only when it is
+  refused and holds more than one package.
+
+  `pin`, `update` and `pristine` now **exit 1** when a package was left
+  unresolved, so `bin/importmap update && git commit` can no longer commit an
+  import map that quietly missed a package. The packages that did resolve are
+  still written.
+- **A CDN that fails mid-crawl leaves the pin alone.** Vendoring a graph makes
+  one request per file — 250 of them for `date-fns` — so a 503 that outlives
+  the retries is far likelier than it was for a single download. `pin` and
+  `pristine` report it (`Skipping "date-fns": Unexpected response code (503)`)
+  and change nothing, rather than taking it for "this package can't be
+  vendored" and converting a working pin to a remote one, which would delete
+  the very files that make it work.
+- **`pristine` reports a package it can't restore and carries on.** It is the
+  repair command, and a pin whose graph the CDN no longer serves the way the
+  pin describes now raises where nothing used to — unrescued, that ended the
+  whole run with a backtrace and left every package after it unrestored. Each
+  one that fails is reported (`Couldn't restore "pdfjs-dist": it can't be
+  vendored as a single file (workers)`), the rest are restored, and the command
+  exits non-zero to say it didn't do all of it — as it does when a dependency
+  of an esm.run bundle, pinned on the way, had to be skipped.
+- **A download the CDN encoded in a way Net::HTTP can't undo is fetched
+  again.** jspm answers some files with `content-encoding: br` whatever the
+  request advertises, and Net::HTTP decompresses gzip and deflate only:
+  `@popperjs/core@2.11.8/lib/utils/computeAutoPlacement.js` arrived as brotli
+  bytes, which read as invalid UTF-8 and took the source inspection down with
+  `ArgumentError: invalid byte sequence in UTF-8`. `pin` now repeats that one
+  request asking for an unencoded body. It doesn't ask up front: supplying an
+  `Accept-Encoding` at all stops Net::HTTP decoding the gzip it does
+  understand. Inherited from importmap-rails, which downloads the same way.
+
+- **`Importmap::Packager::ServiceError` is a class again.** It was assigned
+  `Error.new(Error)` — an *instance* — so `rescue Packager::ServiceError`
+  raised `TypeError: class or module required for rescue clause`, and every
+  jspm service error arrived as a plain `Packager::Error`. Inherited from
+  importmap-rails, where it is still the case.
+- **A failed download no longer deletes the file an app already has.**
+  `pin` and `pristine` removed `vendor/javascript/<package>.js` before
+  fetching, so a CDN that answered 500 — or, now, a file that can't be
+  vendored — left the app with no file at all. The existing file is replaced
+  only once the new one has arrived and been found fit to serve.
+- **`update <package>` moves every pin of that package, not just the bare
+  one.** An app with `pin "pdfjs-dist"` and
+  `pin "pdfjs-dist/build/pdf.worker.min.mjs"` ran `update pdfjs-dist` and got
+  a new main file next to a worker still at the old version — the two are
+  built together and don't tolerate that. A package name now means every
+  key that carries it, the same set `outdated` reports and a bare `update`
+  moves; `update pdfjs-dist/build/pdf.worker.min.mjs` still means that one
+  key.
+- **A subpath pin without a CDN in its comment resolves from the CDN its
+  package's pin names.** The worker pin above, written before provenance
+  existed, was sent to jspm — which can't resolve pdf.js at all — and
+  reported "Couldn't find any packages" on every update while the main pin
+  moved on from jsdelivr. Siblings pinned together come from the same place;
+  the next update records it on the pin. A pin answers for itself first — its
+  own comment, then its own `to:` URL — and only then does its package answer
+  for it, whether that pin is vendored, recording the CDN in its comment, or
+  remote, carrying it in the URL with no comment at all.
+
+- **An array `preload:` survives a rewrite however it is quoted, and
+  `preload: []` stays `preload: []`.** The option was read back through
+  `JSON.parse`, so `pin 'md5', preload: ['admin']` — single quotes being a
+  supported pin shape everywhere else in this gem — took down every command
+  that reads a pin with `JSON::ParserError: unexpected character`. And
+  `preload: []` matched nothing at all, so `pin`, `update` and `pristine`
+  dropped it and quietly restored the `preload: true` default on a package the
+  app had asked to preload for no entry point. `config/importmap.rb` is Ruby,
+  not JSON: the entry points are scanned out of the literal now, and an empty
+  array is written back as one.
+
+- **`pin --vendor` leaves a pin to a custom URL alone.** `--vendor` is meant to
+  override the check that refuses a download, not the URL an app chose to pin,
+  but it reached the vendoring path before the branch that skips custom URLs
+  could run: `bin/importmap pin md5 --vendor` against
+  `pin "md5", to: "https://cdn.example.com/md5.js"` downloaded md5 from
+  whichever CDN the spec resolved to and replaced the line with
+  `pin "md5" # @2.3.0 (vendored)`, without a word about the URL it had just
+  dropped. It now reports the skip the way a plain `pin` does and names the
+  flag in it. Moving such a pin on purpose is still `--from`, which re-resolves
+  it from the CDN you name.
+
+## 1.1.0
+
+### Added
+
+- **Version locks.** `bin/importmap pin luxon@3.7.2 --lock`, or
+  `bin/importmap lock luxon` for a package already pinned, records the lock
+  in the version comment — `pin "luxon" # @3.7.2 (locked)` — and `update`
+  and a plain `pin` skip the package from then on, saying so. A remote pin
+  gains the comment too, carrying the version from its URL. `pin --force`
+  moves a locked package and keeps the lock at the new version; `--no-lock`
+  drops it; `bin/importmap unlock luxon` removes it without touching the
+  file. `pristine` still redownloads a locked vendored package, at the
+  locked version; remote pins are skipped as always. Only the packages
+  named on the command line are locked, never the dependencies a CDN
+  resolves with them, and a locked dependency stays where it is when the
+  package that needs it is pinned or updated.
+- **`update` takes package names, `--all` and `--force`.**
+  `bin/importmap update luxon stimulus-use` re-pins just those, asking the
+  registry about them alone; `update --all` says explicitly what a bare
+  `update` has always done. A named package that is up to date, or has no
+  version to compare, is reported; a name with no pin stops the command
+  before anything is touched. `--force` updates locked packages too and
+  keeps each lock at the new version.
+- **`outdated` shows locks.** A new Locked column marks packages held at
+  their version, and the command exits 1 only when an unlocked package is
+  outdated, so CI stays green for the versions the app chose.
+- **`integrity: true` and `integrity: false` survive a rewrite.** An
+  `update`, `pristine` or `pin` used to drop the option; only an integrity
+  hash, which belongs to the old file, is still removed when the URL changes.
+
+### Fixed
+
+- **`update` no longer re-pins a package the registry couldn't be checked
+  for.** A package whose registry lookup came back unusable has no latest
+  version, so nothing established that it moved — but `update` re-pinned it
+  anyway, letting a bad answer re-resolve the pin against the CDN and carry
+  it to a version nobody asked for. Those packages are now reported —
+  `Couldn't check "md5": Unexpected error response 500: …` — and left where
+  they are; every other package still updates, and the command exits 1.
+  Inherited from importmap-rails, where a bare `update` has always behaved
+  this way.
+- **`update` re-pins a subpath pin instead of appending a bare one.** The
+  registry answers about `photoswipe`, the import map pins
+  `photoswipe/lightbox`, and a bare `update` or `update --all` used to re-pin
+  the name it was answered with: the subpath pin stayed at its old version and
+  a `pin "photoswipe"` was appended beside it — vendored, since a fresh pin
+  has no provenance to say otherwise. Every key carrying an outdated package
+  is now re-pinned, and a package pinned under several keys moves all of them.
+  Only pins that declare a version take part, the same ones `outdated`
+  reports on, so an app file pinned under a package's namespace —
+  `pin "md5/helpers", to: "md5/helpers.js"` — is left alone. Inherited from
+  importmap-rails; `update photoswipe/lightbox` was fixed for the named form
+  in 1.1.0.
+- **A remote subpath pin is re-resolved from the CDN it is on.** Moving
+  `pin "photoswipe/lightbox", to: "https://cdn.jsdelivr.net/npm/photoswipe@5.3.0/…"`
+  back onto jsDelivr asked for `photoswipe/lightbox@5.4.4`, a path no CDN
+  has, so `update` gave up with `Keeping "photoswipe/lightbox" pinned to …
+  (couldn't resolve it from jsdelivr)` and the pin never moved. The version
+  now goes where a CDN expects it, ahead of the subpath —
+  `photoswipe@5.4.4/lightbox`.
+- **A registry that won't answer for one package no longer ends the run.**
+  A 404, a 5xx or a connection that kept resetting used to escape
+  `outdated_packages` once the retries were spent, so `outdated` and
+  `update` died with a backtrace and checked nothing else. The failure is
+  now recorded against that package alone — `outdated` prints the reason in
+  its Latest column, which is what the column was always for — and every
+  other package is still checked. `audit` is unchanged: a registry it can't
+  reach still fails the command outright.
+
 ## 1.0.0
 
 First release of importmap-plus, a drop-in replacement for