esm.sh Instability & Proposal for a Pinning Mechanism

[NadhifRadityo]

Hi everyone,

I’ve been using esm.sh in multiple projects over the past several months, and while it has been extremely helpful, I’ve consistently run into a recurring issue:

Whenever esm.sh updates its server, some of my older projects (1–4 months old) suddenly break. This has happened more than a handful of times (at least 5 so far), and it’s becoming tiring to manually fix projects that were already stable.

I understand that esm.sh is still under active development, and I fully expect some changes to happen. However, this feels like it defeats part of the purpose of migrating to ESM modules, which is supposed to give us ease of use and long-term stability.

I’m not yet a contributor to this repo (and I deeply appreciate the work being done here!), but I’d like to propose/discuss the possibility of a “pinning” mechanism:

• By pinning, I don’t mean just version pinning in the import URL.
• I mean a system where the fetched module files remain completely untouched once published, even after server upgrades.

This would allow developers to rely on esm.sh without fearing that a server-side change will unexpectedly break old projects.

I’d love to hear the community’s thoughts:

• Is something like this already planned?
• Would a pinning mechanism be technically feasible?
• Are there recommended workarounds right now (besides self-hosting)?

Thanks again to the maintainers and contributors for the amazing work on esm.sh!

[ije]

the server wouldn't touch the modules once them are built, even when the server is upgraded. before (<=v135) we introduced the pin query to keep the built stable, in v136 it's no need any more.

https://esm.sh/v134/[email protected]
https://esm.sh/v135/[email protected]

v136 introduces a change to reserve semantic version range, this may break your apps because of lacking lock mechanism:

v135 https://esm.sh/[email protected] -> https://[email protected] (fixed version)
v136 https://esm.sh/[email protected] -> https://scheduler@^0.23.2 (dynamic version)

i'm working on an esm.sh CLI, that can create stable import map:

esm.sh add react-dom@18

↓

<script type="importmap">
{
  "imports": {
    "react-dom": "https://esm.sh/*[email protected]"
  }
  "scopes": {
    "https://esm.sh/": {
      "react": "https://esm.sh/[email protected]",
      "scheduler": "https://esm.sh/[email protected]"
    }
  }
}
</script>