Best practice for publishing libraries that consume the Deno standard library

[jaredkrinke]

I want to publish a "library" module (i.e. one that is intended to be consumed by other modules), and my module depends on functionality in Deno's standard library (deno.land/std).

What's the best way to consume deno.land/std in a library?

(I didn't see any information about this scenario in Linking to external code)

Considerations:

• I'd like the library to work on as many Deno versions as possible
• I don't want to have to update the module for each new Deno/std release (because there are a lot of releases)
• Let's ignore unstable APIs for now (because they generally require explicit versioning)

Edit to add: this situation for Deno's standard library is unique in that the std version is updated often, all the modules are lumped into a single library (with one version), and the std versions are mapped to specific Deno versions (I assume mainly for unstable APIs... hopefully not much else!).

The two options I see are:

1. Import without a version (https://deno.land/std/testing/asserts.ts)
2. Import with a version (https://deno.land/std@0.117.0/testing/asserts.ts)

The first option is attractive, but it seems fragile (especially when Deno 2.0 arrives). The second option is probably best, but I don't like that it duplicates code unless consumers use an import map to align std versions.

Some notes follow:

Import without a version

Note: I haven't found a module that does this.

I see a number of benefits to this:

• My library doesn't need to be updated as bugs are fixed in the standard library
• Multiple libraries will end up using the same standard library code (instead of whatever version the library author happened to use)

But there are significant drawbacks:

• What happens when Deno hits 2.0? Does my module break? Or is std renamed to std2? :)
• My library could break if the standard library subtly changes some behavior I depended upon (intentionally or unintentionally)

Import with a version

Benefits:

• I know exactly what code is running (... until someone uses an import map)
• No worries about Deno 2.0 :)

Downsides:

• If there's a bug in the version of the standard library I use, either I'll have to update the module or all consumers will have to use an import map (and of course an import map can introduce bugs if there are subtle behavior changes between std versions)
• When consuming N different libraries, I'll be pulling in potentially N different copies of standard library modules (unless I use an import map)

Still, this seems like the most reliable option. Consumers that want to align std versions need to use an import map (and hope nothing breaks!), e.g. the following maps @0.117.0 and @0.116.0 to @0.113.0 (I just made up the version numbers):

{
    "imports": {
        "https://deno.land/std@0.117.0/": "https://deno.land/std@0.113.0/",
        "https://deno.land/std@0.116.0/": "https://deno.land/std@0.113.0/"
    }
}

[jaredkrinke]

Note: the Standard library section of the manual recommends specifying a version to avoid breaking changes. This is obviously a good idea for scripts, but I don't see any mention of libraries.

Edit: after reading this section again, I think the most important point is that the standard library hasn't stabilized yet, so "upgrading" any references to std is fraught with peril.

Maybe this question will be more interesting once std has stabilized.