Deno package management questions.

[north anchor]

I have a few questions regarding package management in Deno.

1. Here Deno documentation states that import maps are only applied to applications, and that library authors should prefer the deps.ts pattern.

Contrarily, the jsr documentation specifies that a dependency manifest like the import map in the deno.json file can be used by a library. Does this mean that the deps.ts pattern is now obsolete?

2. How do I use packages published with jsr in a browser environment? Using esm.sh, I can do import ... from "https://esm.sh/[email protected]". Can I do the same with jsr?

3. In jsr, all entry points have to be specified explicitly, so we no longer need to add a package with a trailing slash in the import map to import modules beyond the default entry point. Is this correct?

4. How do I replicate a configuration like this in jsr, specifically specifying external dependencies and aliases?

  "imports": {
    ...
    "@headlessui/react": "https://esm.sh/@headlessui/[email protected]?external=react,react-dom&alias=@types/react:preact/compat",
    ...
  },

[solemn rapids]

1. Regarding the use of deps.ts versus import maps, the documentation does not explicitly state that the deps.ts pattern is obsolete. Instead, it highlights the benefits and limitations of both approaches. The deps.ts pattern is a convention in the Deno ecosystem for managing remote dependencies by re-exporting them from a single file. This makes it easier to manage and update dependencies. On the other hand, import maps allow for the use of bare specifiers and can simplify the process of importing modules. However, import maps are not composable, which means that a library cannot use both bare specifiers and an import map simultaneously, as the top-level project importing that library cannot compose the library’s import map with its own. Therefore, library authors should still use regular, non-bare specifiers (relative or absolute file/HTTP URLs) to ensure compatibility with users' import maps. 🦕

2. For using packages published with jsr in a browser environment, the documentation does not provide a direct example of importing jsr packages in the browser. However, if jsr packages are available via HTTP URLs, you could import them in a similar fashion to how you would with esm.sh, provided that the jsr package is hosted on a server that is accessible from the browser and supports the necessary CORS headers.

3. In jsr, specifying all entry points explicitly does indeed mean that you no longer need to add a package with a trailing slash in the import map to import modules beyond the default entry point. The documentation mentions that the deno: URL scheme will be introduced to handle semver resolution and module deduplication, which simplifies the import process without the need for trailing slashes.

4. Replicating a configuration that specifies external