Resolve, and perhaps control, versions of imported libraries?

[mbostock]

In client.js, we currently load the latest versions of recommended libraries such as D3, Observable Plot, and KaTeX. I think this has a lot of nice properties — it means folks aren’t waiting for us to update the CLI in order to use the latest versions of these libraries so bug fixes and new features automatically reach users, and it’s a lot less work for us to keep updating and re-releasing the CLI whenever recommended libraries have new releases.

But the downside is that users don’t have a way to pin versions to prevent automatic upgrades, if desired. Perhaps in the project’s config file we could expose a dependencies map similar to package.json. This could specify both the semver range for a dependency, and whether it’s loaded from jsDelivr or another CDN or self-hosted. (Related #20.) Perhaps also we could automatically capture unpinned versions the first time they are referenced? Or perhaps we could warn if they are unpinned, and provide a command such as observable add npm:d3 for pinning a dependency?

[mbostock]

Generalizing this:

• We want version control not just for recommended libraries, but any npm: protocol import
• Even if you can’t specify a semver range, it’d be good to resolve the version at build time

In particular, resolving the version of an npm library at build time will avoid some cases where we load duplicate copies of a library. For example, if you load npm:htl and you load npm:@observablehq/inputs which depends on npm:htl, you get two copies of npm:htl because the direct request isn’t versioned (and jsDelivr doesn’t redirect to the versioned request):

• https://cdn.jsdelivr.net/npm/htl/+esm
• https://cdn.jsdelivr.net/npm/[email protected]/+esm

Resolving exact versions has the further benefit that you get immutable caching. 🚀

jsDelivr has a nice API for this: https://www.jsdelivr.com/docs/data.jsdelivr.com#get-/v1/packages/npm/-package-/resolved