Changelog

1.1.0

Added

• Version locks. bin/importmap pin [email protected] --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/[email protected]/…" back onto jsDelivr asked for photoswipe/[email protected], 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 — [email protected]/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 importmap-rails 2.2.3. The Importmap:: API, the pin DSL and the generated import map are unchanged; Importmap::UPSTREAM_VERSION names the importmap-rails release this tracks.

Added

• bin/importmap pin --minify runs a download through bun, esbuild or terser — the first found in node_modules/.bin or on PATH, including Windows .cmd shims — before it lands in vendor/javascript. Always transform-only, so bare import specifiers stay exactly as the CDN resolved them and the import map keeps resolving them. pristine --minify does the same for everything already vendored. Plenty of packages publish unminified ESM (pdfjs-dist, choices.js, luxon), and a CDN serving package files hands them out as published.
• --from esm.run pins jsDelivr's bundled builds instead of a package's own dist file. A bundle references its dependencies as absolute /npm/[email protected]/+esm imports, which resolve only on jsDelivr; those are rewritten to bare specifiers on download and each dependency without a pin is vendored the same way. A dependency the app already pins is left alone, so the bundle resolves to the version the app chose. Versions resolve through jsDelivr's data API, so pin luxon@3 and pin apexcharts/core work as they do on npm.
• Provenance in the pin comment. A vendored pin records the CDN when it isn't jspm and whether the file was minified — pin "luxon" # @3.7.2 (esm.run, minified). update, pristine and a plain pin read it back, so a package keeps its CDN and stays minified without repeating the flags. This extends to every CDN: an unpkg download no longer silently moves back to jspm on the next update.
• An explicit --from moves a remote pin to that CDN, instead of being overruled by the provider the pin already points at.
• Requests retry. A reset connection, a timeout or a 429/5xx from the CDN is tried up to three times with a growing pause before bin/importmap gives up, and the failure then names the URL instead of a raw backtrace. Importmap::Packager.retry_attempts / retry_wait tune it.

Changed

• bin/release tags a version and publishes a GitHub Release, which fires .github/workflows/release.yml to push the gem over RubyGems trusted publishing. The upstream script pushed from a developer's machine with an API key.