feat(unstable): package manager

[dsherret]

Note: Extremely experimental

As discussed in https://deno.com/blog/package-json-support#a-new-major-version and #17495 but making the specifiers non-Deno specific.

This PR adds an unstable built-in package manager to Deno, but it is currently not usable because the registry infrastructure hasn't been setup and it points to a non-existent url by default. The default registry url can be configured via the DENO_REGISTRY_URL environment variable.

Using and installing packages

Packages are referenced via semvered specifiers, which can be defined in an application or package's import map:

// deno.jsonc
{
  "imports": {
    "path": "jsr:@std/path@1"
  }
}

Next, use the specifier in a JavaScript or TypeScript file:

// main.ts
import * as path from "path";

console.log(path.join("folder", "main.json"));

Then it's as simple as:

$ deno run main.ts
folder/main.json

Inline specifiers

Of course, these specifiers can be directly used inline in the code, which is useful for single file scripts or when distributing code:

import { readInt } from "jsr:@std/io@1/read_int";
// ...etc...

Details

1. There is no separate install command.
   • Packages are automatically updated based on what's in the code. This works similarly to Rust's cargo run.
   • There is no need to have to remember to run a separate install command on first run or when the dependencies are upgraded (a significant source of wasted time other ecosystems)
2. These specifiers resolve to https: specifiers.
   • The underlying https: specifiers can be imported without duplication of a module.
   • Tooling to generate an import map that can then be used in browsers and other tooling will be added in the future.
   • All existing Deno tooling works well with these because everything is still https: specifiers under the hood.
3. These specifiers are much faster on first run than https: specifiers because there is no waterfalling within a package and the module graph information is computed ahead of time and distributed by the registry.
4. These specifiers are efficient because only the imported code is downloaded.

The specific details on how packages might be created and distributed will be outlined soon for further discussion before stabilization. Again, to emphasize, this is all unstable experimental work.

Ref #17475
Ref #17495 -- won't close that one until this is fully functional

[dsherret]

This is some additional cleanup I forgot to do in #20504

[dsherret]

[ry]

LGTM

[bartlomieju]

LGTM

[bartlomieju]

How are these files getting served?

[dsherret]

This isn't part of the test registry which is in testdata/jsr/registry, so this is just a normal file in the testdata directory.

[lilnasy]

What does jsr mean? Is it an acronym?

[rojvv]

[dsherret]

I'm not requiring an --unstable flag here at the moment because this feature is currently not usable so it will error every time anyway.